NGINX Security Response Headers & CSP Prompt
Add a correct, non-breaking security header baseline in NGINX — Content-Security-Policy, HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, frame controls — applied so headers survive error responses and don't get silently dropped by add_header inheritance rules.
- Target user
- Engineers hardening HTTP response headers on an NGINX site
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior application-security engineer who adds HTTP security headers to NGINX correctly. You know `add_header` inheritance is a trap and that a strict CSP can break a working site if shipped enforcing on day one. I will provide: - My current `server`/`location` blocks (including any existing `add_header`): [PASTE CONFIG] - What the site is (static, SPA, app with inline scripts, third-party widgets/analytics): [DESCRIBE] - The origins the page legitimately loads scripts/styles/images/fonts/frames from: [LIST] - Whether the site is HTTPS-only and whether HSTS/preload is acceptable: [DESCRIBE] - Whether the site should ever be framed (embeds) or never: [DESCRIBE] Design the header baseline: 1. **Core headers** — `X-Content-Type-Options: nosniff`, `Referrer-Policy`, `Permissions-Policy`, `X-Frame-Options`/frame-ancestors, and `Strict-Transport-Security` (only if HTTPS-only; preload only if I confirm). Use `add_header ... always` so headers apply to 4xx/5xx too. 2. **Content-Security-Policy** — build a CSP from the origins I listed (`default-src`, `script-src`, `style-src`, `img-src`, `font-src`, `connect-src`, `frame-ancestors`, `base-uri`, `form-action`). Prefer nonces/hashes over `unsafe-inline`; if the site needs inline scripts, explain the least-bad option. 3. **Report-Only rollout** — deliver the CSP first as `Content-Security-Policy-Report-Only` with a `report-uri`/`report-to`, so I can find violations before enforcing. Give me the switch to enforcing once clean. 4. **Inheritance safety** — audit MY config for nested blocks with their own `add_header` that would drop the inherited security headers, and show how to re-declare or centralize them (e.g. an `include` snippet) so every route is covered. 5. **Don't duplicate** — if my upstream already sets some of these, tell me to `proxy_hide_header` the upstream copy or set them only in one place, to avoid duplicate/conflicting headers. Output: (a) a reusable `security-headers.conf` snippet plus where to `include` it; (b) the CSP in Report-Only form and the enforcing version; (c) the inheritance fixes for my specific blocks; (d) `curl -I` checks for the homepage AND a nested route AND an error page; (e) `nginx -t` verification. Apply only after `nginx -t` passes and reload.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
The add_header inheritance rule is one of NGINX’s sharpest edges: the moment a child location defines its own add_header, it stops inheriting the parent’s — silently dropping every security header on that route. Teams verify the homepage, see the headers, and ship, not realizing the login or API path is bare. This prompt makes an inheritance audit and multi-route curl -I checks mandatory.
CSP is the header most likely to break a live site. Rolled out enforcing, a strict policy blocks inline scripts, analytics, and third-party widgets instantly. The Report-Only-first workflow lets you collect real violations from real traffic and tighten the policy to reality before flipping to enforcing — turning a risky big-bang into a measured rollout.
Centralizing the headers in an include-able snippet (and using always so they cover error responses) makes the baseline consistent and auditable, and the guidance to avoid duplicating upstream headers prevents the conflicting-header bugs that confuse browsers and scanners alike.
Related prompts
-
NGINX Config Security Audit Prompt
Audit an NGINX config for the classic misconfigurations — version leakage, missing security headers, open proxy, path traversal, exposed dotfiles — and get a prioritized fix list with exact directives, not a generic checklist.
-
NGINX Canary & Blue-Green Routing Prompt
Design percentage-based canary and blue-green traffic routing in NGINX using split_clients and upstream weighting — with a sticky cohort, an instant rollback path, and a way to force yourself onto the canary for testing.
-
NGINX CORS & Preflight Proxy Prompt
Get correct, secure CORS handling in NGINX for a reverse-proxied API — OPTIONS preflight, Access-Control-* headers, credentials, and per-origin allow-listing — without the classic duplicate-header and wildcard-with-credentials footguns.
-
NGINX Custom Error Pages & Fallback Prompt
Design clean custom error pages and graceful fallbacks in NGINX — branded 404/50x pages, an upstream-down maintenance page, and error interception that doesn't leak backend errors or break API JSON responses.
More NGINX prompts & error guides
Browse every NGINX prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.