Malinois
Security guides
Malinois Field Guide

Security headers checklist

Security headers tell browsers which behaviors your site permits. They cannot repair broken authorization or remove a leaked key, but they can reduce the impact of injection, framing, downgrade, and data-leak mistakes.

Test the response users actually receive

Check the final HTTPS response after redirects, not only an origin or local server. A CDN, reverse proxy, or framework can add, remove, or replace headers on the way to the browser.

Policies should match the deployed application. Copying a strict policy without testing can break sign-in, payments, analytics, images, or API calls; copying a permissive one can provide little protection.

Header-by-header review

  1. Content-Security-Policy

    Start with the sources the app truly needs for scripts, styles, images, connections, and frames. Remove wildcards and unsafe allowances where the application can operate without them.

  2. Strict-Transport-Security

    After confirming the entire host works over HTTPS, instruct browsers to stay on HTTPS. Include subdomains only when every subdomain is ready.

  3. Frame protection

    Use CSP frame-ancestors to state who may embed the site. Add X-Frame-Options for older clients when that matches the same intent.

  4. X-Content-Type-Options

    Set nosniff so browsers respect declared content types. Also serve scripts and styles with the correct Content-Type.

  5. Referrer-Policy

    Choose how much destination sites may learn about the source URL. Avoid putting secrets or personal data in URLs regardless of the policy.

  6. Permissions-Policy

    Disable camera, microphone, location, and other browser features the app does not use. Grant only the capabilities a real feature requires.

  7. Recheck key routes

    Inspect the homepage, sign-in, dashboard, API responses, errors, and static assets. Headers on one route do not prove coverage everywhere.

Common false confidence

  • A header scanner passes the homepage while authenticated or error routes differ.
  • A CSP exists but allows every host, inline script, or dynamic evaluation.
  • HSTS is enabled before all subdomains support HTTPS.
  • A platform dashboard shows a setting that is absent from the final response.

Change policies in small, observable steps

Use browser developer tools and application tests after each policy change. When possible, trial a CSP in report-only mode, review violations, then enforce the smallest policy that supports intended behavior.

Check the deployed app, not just the checklist

With the owner’s authorization, Malinois reviews public responses for exposed files, secrets, database access signals, and missing security headers.

Run a free passive scan

Passive external review only. No exploitation or penetration testing.

Continue the review

AI app security checklist

A launch-to-maintenance workflow covering access, data, dependencies, recovery, and verification.

Read guide →

Prevent API key leaks in web apps

Keep provider keys out of public bundles, logs, repositories, and unsafe client-side workflows.

Read guide →