Web security basics
PHP site security headers: what a missing header means
Security headers can add browser-side protections, but each header has a specific purpose and deployment context. An absent header is an observation to assess, not proof that a site is compromised. A present header does not fix PHP runtime vulnerabilities or replace secure application design.
Match the header to the response and feature
HTTPS protects data in transit when correctly configured. HSTS tells browsers that have received the policy to prefer HTTPS, but domains should test subdomains before enabling includeSubDomains and understand the long-lasting effects of preload. Content Security Policy can restrict where a browser loads content, but a policy must fit the site's scripts, styles, integrations, and reporting needs.
X-Content-Type-Options: nosniff helps browsers respect the declared media type. Framing controls such as CSP frame-ancestors can reduce clickjacking exposure where embedding is not a required feature. OWASP notes that the usefulness of a header depends on the kind of response; a JSON API or redirect does not have the same interaction surface as a page with forms and buttons.
Treat scanner output as a prompt for review
A check against one homepage response cannot establish that every route, subdomain, login flow, or API response uses the same policy. A web application may intentionally permit a partner frame or use third-party services that need to appear in its CSP. The right outcome is a short review of the actual feature and policy, followed by a tested change.
PHP2Shell is a separate server-runtime issue. Adding HSTS or CSP cannot patch PHP core. Owners should verify the PHP package through their host and address each browser-header issue on its own evidence.
A header may differ between cached and uncached responses or between static and dynamic paths. Test several representative routes and inspect browser reports before enforcing a policy; document exceptions so a later change does not silently weaken protection across the whole site.
Roll headers out deliberately
Start with report-only or a limited policy where supported, review browser reports, and test high-value flows before enforcement. Roll out HSTS after confirming HTTPS across affected hostnames. Keep a record of the response path and header value observed so later checks can distinguish configuration changes from unrelated proxies or cached responses.
Common questions
Does a missing browser header show PHP2Shell exposure?
No. Headers are browser-policy signals; PHP2Shell concerns the server runtime and needs separate package evidence.
Should I copy another site's Content-Security-Policy?
No. Inventory required assets, test a tailored policy and verify important flows before enforcement.
Can every website use the same policy?
No. Application behavior and dependencies differ; treat header advice as a design prompt, not universal configuration.