astro-security

Astro Security

Core Security Model

Understand that Astro's static-first architecture provides inherent security advantages. Static HTML has a minimal attack surface because there is no server-side code executing at request time. However, when you enable SSR or hybrid rendering modes, you introduce server-side attack vectors that require explicit hardening. Configure security centrally in astro.config via the security object. Treat every SSR endpoint and server island as a potential attack surface that needs validation, authentication, and input sanitization.

When working in static-only mode, focus your security efforts on build-time data validation and Content Security Policy headers. When working in SSR or hybrid mode, apply the full set of protections described below.

Content Security Policy (Astro 6)

Enable the built-in CSP support by adding security: { csp: true } to astro.config. When enabled, Astro automatically generates nonces for inline scripts and styles, injecting them into both the HTML and the CSP header. This prevents XSS attacks by blocking any script or style that does not carry a valid nonce.

// astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  security: {
    csp: true
  }
});

Be aware that View Transitions may conflict with strict CSP policies. Test thoroughly when combining security.csp with <ViewTransitions />. If you encounter issues, consider using a custom CSP header via middleware instead of the built-in option.

For custom CSP headers or when you need fine-grained control over directives, inject the Content-Security-Policy header in middleware:

// src/middleware.ts
export const onRequest = async (context, next) => {
  const response = await next();
  response.headers.set(
    'Content-Security-Policy',
    "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;"
  );
  return response;
};

XSS Prevention & set:html (CRITICAL)