TechnicalCollectible prompt
Security headers and a CSP rolled out in report-only
Act as a senior application security engineer. Add security headers and a Content Security Policy to my {{tech_stack}} site at {{website_url}}. Third-party services it loads: {{integrations}}. Before changing anything, find where headers are set today (host config, middleware, framework config or CDN) and tell me what's already sent.
Headers on every response:
- Strict-Transport-Security with a max-age of one year and includeSubDomains; add preload only after I confirm every subdomain serves HTTPS
- X-Content-Type-Options nosniff
- Referrer-Policy strict-origin-when-cross-origin
- Permissions-Policy turning off camera, microphone, geolocation and payment unless we use them
- Cross-Origin-Opener-Policy same-origin, unless it breaks a sign-in or payment popup
- frame-ancestors in the CSP to stop clickjacking, plus X-Frame-Options DENY for older browsers
Content Security Policy, in stages:
1. Inventory every script, style, font, image, frame and connection source the site actually uses, page by page
2. Write a strict policy: default-src 'self'; script-src with per-request nonces or hashes and 'strict-dynamic', never 'unsafe-inline' or 'unsafe-eval'; object-src 'none'; base-uri 'self'; form-action 'self' plus any payment provider
3. Ship it as Content-Security-Policy-Report-Only with a reporting endpoint that stores reports without personal data
4. Review reports for one to two weeks, fix real violations, and ignore noise from browser extensions
5. Then enforce it, keeping the reporting endpoint on
Rules: never add a wildcard source or 'unsafe-inline' for scripts just to silence a violation; find the inline script and move it or hash it. Keep the policy defined in one place.
Finish with the final headers, what each one blocks, a scan from a tool such as Mozilla Observatory before and after, and anything still allowed with the reason.
Technicalnvoka.com/library/nvoka-security-headers-and-content-security-policyScan to open
Technical
Security headers and a CSP rolled out in report-only
Add the headers that block common attacks, and test a Content Security Policy before enforcing it.
Curated by Nvoka
Claude CodeCursorCodexWindsurf
Make it yours
Fill in the blanks and change any word. Only your copy changes, never the card.
Fill in the blanks
0 of 3 filledYour prompt
Act as a senior application security engineer. Add security headers and a Content Security Policy to my {{tech_stack}} site at {{website_url}}. Third-party services it loads: {{integrations}}. Before changing anything, find where headers are set today (host config, middleware, framework config or CDN) and tell me what's already sent.
Headers on every response:
- Strict-Transport-Security with a max-age of one year and includeSubDomains; add preload only after I confirm every subdomain serves HTTPS
- X-Content-Type-Options nosniff
- Referrer-Policy strict-origin-when-cross-origin
- Permissions-Policy turning off camera, microphone, geolocation and payment unless we use them
- Cross-Origin-Opener-Policy same-origin, unless it breaks a sign-in or payment popup
- frame-ancestors in the CSP to stop clickjacking, plus X-Frame-Options DENY for older browsers
Content Security Policy, in stages:
1. Inventory every script, style, font, image, frame and connection source the site actually uses, page by page
2. Write a strict policy: default-src 'self'; script-src with per-request nonces or hashes and 'strict-dynamic', never 'unsafe-inline' or 'unsafe-eval'; object-src 'none'; base-uri 'self'; form-action 'self' plus any payment provider
3. Ship it as Content-Security-Policy-Report-Only with a reporting endpoint that stores reports without personal data
4. Review reports for one to two weeks, fix real violations, and ignore noise from browser extensions
5. Then enforce it, keeping the reporting endpoint on
Rules: never add a wildcard source or 'unsafe-inline' for scripts just to silence a violation; find the inline script and move it or hash it. Keep the policy defined in one place.
Finish with the final headers, what each one blocks, a scan from a tool such as Mozilla Observatory before and after, and anything still allowed with the reason.