How to check CSP/CORS/cache settings by parsing HTTP headers

Conclusion: What to check first

First, obtain the final response for the HTML document and check Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options or frame-ancestors, Referrer-Policy, and Permissions-Policy against their intended purposes.

What is being checked is the final response received by the browser. Don't confuse request and response headers, and record each response separately if there are redirects.

Get and check the actual headers

Select the target communication in Network in Chrome DevTools and copy the Response Headers. If you want to check with CLI, use curl -I or curl -v and paste the obtained content as is into the analysis tool.

HTTP/2 200
content-security-policy: default-src 'self'
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin

• Check the HTML document and API separately
• Verify HSTS in an HTTPS response
• Compare CSP with the sources actually required
• Evaluate insufficient display against the threat model.

Role of header and how to read it

It reads not only whether a header is present, but also its value, what it applies to, and its combination with related headers. The required settings are different for the page body, API, and static files.

Common configuration mistakes

Checking only by scoring header names, assigning the same value to APIs and HTML, checking only responses before CDN deployment, or mistaking report-only CSP for enforced CSP can overlook actual browser behavior.

• Present in the configuration file but absent from the public response
• Values differ between the redirect response and the final 200 response
• The pre-change value remains in the CDN cache
• Not applied only to specific paths or error pages

Mechanically applying one recommended value to all pages may break embedding, authentication, external resources, and API communication. Prioritize phased introduction and actual measurements.

Separate including web server/CDN

Even if the configuration file looks correct, another layer may have deleted or overwritten it in the public response. Let's compare step by step from the app to the browser.

Recommended values vary by site configuration. In particular, CSP, Permissions-Policy, COOP, COEP, and CORP restrict functionality, so use Report-Only or a test environment to check the impact before enforcing them.

Retest under the same conditions after correction

After the fix, check HTML, APIs, static assets, and error pages, and also check browser console CSP violations and CORS errors.

• Re-fetch with the same URL, HTTP method, and authentication status
• Check the pre-redirect and final responses separately
• Check by changing the path type such as HTML, API, static file, etc.
• Consider CDN caching and save raw headers before and after modification

Tool range and references

The HTTP header analysis tool analyzes the pasted request/response within the browser and masks sensitive values in the initial state. The URL field is only used in the context of the judgment and does not perform communication to the target site, redirect tracking, vulnerability diagnosis, or score evaluation.

Practical confirmation example

Get the headers for the same path in production and validation environments and compare the difference in values. In addition to the configuration file, the final response sent to the browser is left as a trail.

Make corrections one item at a time, re-fetch with DevTools or curl, and then update the parsing results.

1. Record the target URL, confirmation time, and environment
2. Store requests and responses separately
3. Check the warning reason and related headers in the analysis tool
4. Decide where to grant it: app, web server, proxy, CDN
5. Re-acquire under the same conditions and check the difference

Be sure to mask authorization, cookies, set-cookies, API keys, etc. before sharing. Analysis results do not guarantee safety.

Frequently asked questions

If I see that a header is missing, can I immediately identify a vulnerability?

No. These checks are clues for reviewing purpose, delivery path, and whether the policy is applied in the browser. Make the final decision based on your application's design and threat model.

Can I get the header of a public site just by entering the URL?

No. Paste headers captured from DevTools, curl, or server logs, or load them from a text file. The input is parsed in your browser.