Security headers tell browsers how to handle parts of a website's security behaviour. They can reduce certain risks, but they do not replace secure application code, maintained software or HTTPS. Add them carefully, check the actual responses and keep a rollback copy of the working server configuration.
This guide replaces the previous security-headers page. It is general guidance for a site you manage, not a promise that every customer website automatically has the same headers. Your web server, application and any proxy can each affect the final response. Test the complete path visitors use.
Begin with working HTTPS
Confirm that a valid certificate covers the intended hostname and that important pages load over HTTPS before changing strict transport rules. An HSTS policy tells browsers to use HTTPS for future requests, so a mistaken policy can make an existing certificate problem harder for visitors to bypass.
Read the free SSL setup guide before forcing secure connections. Be particularly careful with subdomain coverage: a policy that includes subdomains can affect services beyond the main website. Do not copy a long-lived policy until you understand which hostnames it will cover.
Understand the purpose of each header
Content-Security-Policy controls which sources a page may use for scripts, styles, images, frames and other resources. A restrictive policy can reduce exposure to some injection attacks, but an incorrect one can block legitimate application features. Begin by inventorying the sources the site actually needs.
X-Content-Type-Options with nosniff asks browsers not to reinterpret certain resource types. Referrer-Policy controls how much referring-page information is sent with requests. Frame restrictions can limit where the site is embedded, while Permissions-Policy can restrict selected browser capabilities.
Each control has its own meaning and limitations. A list of headers is not a security certification. Use the MDN HTTP header reference for definitions and check behaviour against the browsers and application features you support.
Back up configuration before editing
If you manage Apache-compatible rules through .htaccess, preserve the working file before changing it. Keep a copy outside the public directory and record which application or control panel also edits the file. A later automated update may replace a manual change if ownership is unclear.
Do not paste a second set of front-controller or redirect rules into an unfamiliar application. The file may already handle authorization headers, routing, HTTPS and protected paths. Make a narrow change and check syntax and responses before broadening it.
The cPanel hosting overview describes the included control panel. Access to a file manager does not mean every server directive is permitted. If the server rejects a directive or returns an error, restore the known working file and ask support about the supported configuration.
Introduce a content security policy gradually
Inventory first-party assets and necessary external services, including analytics, fonts, embeds and payment widgets. Use a report-only policy where appropriate to observe violations before enforcement. Do not disable a payment or authentication feature merely to make a scanner report fewer allowed sources.
Test the real pages and interactions after each change. A home page may work while an account page needs another script or frame source. Inspect the browser console and network responses, and distinguish an expected blocked resource from a feature the application genuinely needs.
Avoid broad claims that a policy makes the site secure. CSP is a defence layer whose value depends on the actual directives and application. Keeping unsafe allowances may be necessary during migration, but it should be an intentional compatibility decision rather than an unexplained copied setting.
Check headers on the final response
Use browser developer tools or a read-only HTTP request to inspect the response visitors receive. Check normal pages, redirects and error responses. A header set by the application can be changed or duplicated by the web server or a proxy, so inspect the public result rather than only the configuration file.
Test mobile navigation, forms, account access and any payment-related widget without completing a real transaction. Keep before-and-after observations so you can identify a regression. If a critical journey breaks, revert the change and investigate the specific blocked dependency.
Headers complement the broader maintenance plan described in the provider checklist. If you need hosting, review the current plan specifications and support scope. Do not infer a managed security service, WAF or DDoS feature that has not been confirmed.