Security headers
Configure browser security policies for Easel applications.
HTTP response headers can reduce the impact of cross-site scripting, framing, MIME confusion, and information leakage.
Easel may set infrastructure-level headers, but application-specific browser policies remain your responsibility.
Content Security Policy
Content Security Policy (CSP) restricts which resources a browser may load and execute.
Example starting point:
A real CSP must account for the application’s scripts, styles, images, APIs, fonts, frames, and development tooling.
Roll out CSP carefully:
- Begin with
Content-Security-Policy-Report-Only. - Collect violation reports.
- Remove unsafe dependencies.
- Narrow allowed sources.
- Enforce the policy.
Avoid adding broad values such as *, 'unsafe-inline', or 'unsafe-eval'
without understanding the tradeoff.
HSTS
HTTP Strict Transport Security instructs browsers to use HTTPS.
Example:
Only add includeSubDomains when every subdomain supports HTTPS.
Only request preload after verifying the domain meets browser preload requirements and the policy can be maintained.
See HTTPS and TLS.
Framing
Prevent unauthorized framing with CSP:
X-Frame-Options remains useful for older clients:
Use SAMEORIGIN or an explicit CSP allowlist when legitimate embedding is
required.
MIME sniffing
This helps prevent browsers from interpreting a response as a different content type.
Referrer policy
Example:
Choose a policy based on analytics and privacy requirements.
Permissions policy
Permissions Policy controls browser features such as camera, microphone, and geolocation.
Example:
Framework configuration
Configure headers using your framework’s supported mechanism (for example Next.js
headers in next.config).
See also Request and response headers for platform headers Easel may set on CDN responses.