DPDP Section 8 security headers — the exact HTTP-header stack Indian websites should ship

Section 8(5) of the DPDP Act requires Data Fiduciaries to take 'reasonable security safeguards' to prevent personal data breach. The clause is open-ended by design, but the Data Protection Board will read it against the same baselines that CERT-In, RBI and ISO 27001 already use — and that baseline starts with HTTP response headers. The cost of getting these right is one config commit. The cost of getting them wrong is sitting in the highest penalty band the Act offers.

**1. Strict-Transport-Security (HSTS).** Forces every subsequent request to your domain to use HTTPS, even if the user types http://. Recommended value: `Strict-Transport-Security: max-age=15552000; includeSubDomains; preload`. The six-month max-age is the minimum to be eligible for the browser HSTS preload list. Caveat: only enable includeSubDomains once every subdomain (staging, blog, admin, status) serves HTTPS — otherwise you brick them. Roll out in three stages: max-age=300 for a day to verify, then max-age=86400 for a week, then the six-month value.

**2. Content-Security-Policy (CSP).** The single highest-impact header for breach prevention — controls which scripts, images, fonts and frames the browser will load on your page. A tight CSP makes most XSS attacks impossible. Starting value: `Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' 'unsafe-inline'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; frame-ancestors 'self'; report-uri /csp-report`. Ship in Report-Only mode for two weeks, collect violations, narrow the policy, then flip to enforcement. Without `'unsafe-inline'` the first day, you will likely break analytics; with it, you keep coverage while you migrate inline scripts to nonces.

**3. X-Frame-Options.** Stops clickjacking — another site embedding yours in an iframe and tricking users into clicking. Recommended value: `X-Frame-Options: DENY` (or `SAMEORIGIN` if you legitimately embed your own pages). CSP's `frame-ancestors` directive supersedes this in modern browsers, but X-Frame-Options is still needed for older clients.

**4. X-Content-Type-Options.** One value: `X-Content-Type-Options: nosniff`. Stops browsers from guessing a file's MIME type and executing things they should not. Zero risk to set, blocks a whole class of upload-attack vectors.

**5. Referrer-Policy.** Controls how much of the previous URL you leak to other sites your users navigate to. Recommended value: `Referrer-Policy: strict-origin-when-cross-origin` — sends the full URL to same-origin destinations, only the origin to cross-origin destinations, and nothing on downgrade from HTTPS to HTTP. This is what most privacy-conscious Indian fintechs and healthtechs ship by default.

**6. Permissions-Policy.** Disables browser features your site does not need — camera, microphone, geolocation, payment APIs, USB. Recommended starting value: `Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()`. Opt-in features you do need. The `interest-cohort=()` value explicitly disables FLoC / Topics on browsers that ship it, which removes a tracking surface you almost certainly do not want under Section 6.

**7. Cross-Origin headers (the three).** `Cross-Origin-Opener-Policy: same-origin`, `Cross-Origin-Resource-Policy: same-origin`, and `Cross-Origin-Embedder-Policy: require-corp`. These three together enable browsers' strict origin isolation and protect against Spectre-class side-channel attacks. The third one (COEP) is the most likely to break embeds — start with the first two, add the third after you have audited what your pages embed.

**Where to ship the headers from.** If you are on Cloudflare, use a Transform Rule under HTTP Response Header Modification — applies to every request including static assets, no code change needed. If you are on Vercel, add them to `vercel.json` under the `headers` block (this site already does some of this — search [vercel.json](vercel.json)). If you are self-hosted, Nginx's `add_header` directive in the server block is the standard pattern. Always set headers at the edge layer, not in application code — application code is bypassable for static asset requests.

**How to verify.** Run your domain through securityheaders.com — a free third-party scanner that grades A+ to F based on the headers above. Aim for A or A+. Then re-run the [checkDPDP scanner](/scan) — the security-headers check is one of the ten categories, and a Fail there is what scales your Section 8(5) exposure into the high penalty band. The scanner's evidence — a screenshot of an A-graded headers report — is the documentation you hand to a Data Protection Board officer when they ask about your safeguards.

**What headers alone do not cover.** HTTPS hygiene, password policy, backup encryption, vendor DPAs, patching cadence, breach-response playbook. Headers are the first quartile of Section 8 — they close the visible-from-the-browser surface that scanners and enforcement officers will look at first. The deeper baselines are covered in the [Section 8 minimum-security-stack post](/blog/section-8-minimum-security-stack-india).