Fix Security Misconfiguration in Nitro

Nitro's high-performance engine is a double-edged sword. Misconfiguring runtime configs or omitting essential security headers transforms your edge-side logic into an information disclosure goldmine. We're locking down the engine to prevent environment leakage and browser-based exploits by strictly isolating secrets and enforcing transport-layer security.

The Vulnerable Pattern

// nitro.config.ts
export default defineNitroConfig({
  runtimeConfig: {
    public: {
      // CRITICAL VULNERABILITY: Sensitive keys exposed to the client-side bundle
      stripeSecret: 'sk_live_51Mz789...',
      dbPassword: 'admin_password123'
    }
  }
});

The Secure Implementation

Security misconfiguration in Nitro typically manifests through environment leakage and missing transport security. Nitro’s `runtimeConfig` is split into 'private' (root level) and 'public'. Placing secrets inside the `public` key serializes them into the client-side payload, making them accessible to any user via the browser console or network inspection. Furthermore, Nitro does not inject security headers by default. You must use `routeRules` to define a Content Security Policy (CSP), HSTS, and frame protection. This configuration ensures secrets stay server-side and the browser is instructed to block common injection and clickjacking vectors.

// nitro.config.ts
export default defineNitroConfig({
  runtimeConfig: {
    // Private: Only available on the server-side Nitro context
    stripeSecret: process.env.STRIPE_SECRET,
    dbPassword: process.env.DB_PASSWORD,
    public: {
      // Public: Safe for the browser/client access
      apiBase: '/api/v1'
    }
  },
  // Hardening headers via Nitro Route Rules
  routeRules: {
    '/**': {
      headers: {
        'Content-Security-Policy': "default-src 'self';",
        'X-Frame-Options': 'DENY',
        'X-Content-Type-Options': 'nosniff',
        'Strict-Transport-Security': 'max-age=31536000; includeSubDomains'
      }
    }
  }
});