What Are HTTP Headers?

HTTP headers are instructions sent by a web server to a visitor’s browser along with a website’s content. These instructions tell the browser how to handle the content; for example, they can enforce security policies, manage caching, or provide information about the server.

The Pressable platform is secure by default, but you may want to add custom headers to meet the requirements of a security scanner or to enable advanced functionality. This guide explains the correct way to add them.

How to Add Custom Headers

The safest and most direct way to add custom headers to your site is by using a special file in your site root directory (/htdocs) called custom-redirects.php. If this file does not already exist, you can create it. The platform will automatically include this file when your site loads.

Steps:

1. Connect to your site using SFTP, you should be in /htdocs when you connect.
2. Create or edit the file named custom-redirects.php.
3. Add your header() functions to this file.

You can also create or edit the file using a file manager plugin. Please see our guide here for how to configure your file manager’s site root correctly.

Example:

<?php // Add custom headers to your site. // Each header should be on its own line. header('X-Content-Type-Options: nosniff'); header('X-Frame-Options: SAMEORIGIN'); header('Referrer-Policy: no-referrer-when-downgrade'); header('X-XSS-Protection: 1; mode=block');

Commonly Requested Security Headers

Many customers contact us after a security scan suggests adding specific headers. Here is a breakdown of the most common ones.

Content-Security-Policy (CSP)

What it does: A powerful header that helps prevent attacks like cross-site scripting (XSS). It does this by specifying which dynamic resources (scripts, styles, images, etc.) are allowed to load on your site.

Why we don’t set it by default: A CSP is extremely specific to each site. A default policy would almost certainly break custom themes, plugins, and third-party services (like Google Analytics or marketing pixels). It must be configured carefully by the person who knows the site best: you.

Example:
header("Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com;");

Learn More: Content-Security-Policy on MDN

Permissions-Policy

What it does: Allows you to control which browser features (like the camera, microphone, or geolocation) can be used on your site and its <iframe> embeds.

Why we don’t set it by default: Similar to CSP, the necessary permissions depend entirely on your site’s functionality. A restrictive default policy could disable expected features.

Example:
header("Permissions-Policy: geolocation=(), microphone=()");

Learn More: Permissions-Policy on MDN

X-Frame-Options

What it does: Protects your visitors from “clickjacking” attacks by controlling whether your content can be displayed within an <iframe> on other websites.

Example:
header('X-Frame-Options: SAMEORIGIN');

Learn More: X-Frame-Options on MDN

Referrer-Policy

What it does: Controls how much referrer information (the page a visitor came from) is sent when a user clicks a link that goes from your site to another. This is important for user privacy.

Example:
header('Referrer-Policy: strict-origin-when-cross-origin');

Learn More: Referrer-Policy on MDN

X-XSS-Protection

What it does: Enables the browser’s built-in cross-site scripting (XSS) filter, instructing it to block the page if an attack is detected. This provides an extra layer of defense against reflected XSS vulnerabilities.

Example:
header('X-XSS-Protection: 1; mode=block');

Why you might use it (and why it’s not set by default): Modern browsers (like Chrome and Firefox) have deprecated or disabled X-XSS-Protection in favor of CSP and more robust protections. Additionally, incorrect settings can create a false sense of security or even introduce issues. It’s only useful if you’re relying on legacy browser behavior and have confirmed the default browser protection is insufficient.

Learn more: X-XSS-Protection on MDN

Other Useful Headers

Cross-Origin Resource Sharing (CORS)

What it’s for: If you host web fonts or use APIs that need to be accessed from other domains, you may need the Access-Control-Allow-Origin header. This tells browsers that it is okay for scripts on other domains to request resources from your site.

Example:
header("Access-Control-Allow-Origin: https://another-domain.com");

Learn More: Access-Control-Allow-Origin on MDN

X-Robots-Tag

What it’s for: This provides instructions to search engine crawlers (like Googlebot) about how to index a page. It is useful for controlling the indexing of non-HTML files like PDFs or for setting sitewide indexing rules.

Example:
header("X-Robots-Tag: noindex, nofollow”, true);

Learn More: X-Robots-Tag Specifications

Headers You Should Not Add

Attempting to set certain headers can conflict with our platform’s optimizations.

Caching Headers (Cache-Control, Expires, Pragma)

Pressable’s platform includes a highly optimized, multi-layered caching system. Our servers automatically send the correct caching headers for you. Overriding these headers in PHP will interfere with our systems and may reduce your site’s performance.

HTTP Strict-Transport-Security (HSTS)

The Strict-Transport-Security header is essential; it forces browsers to only use a secure HTTPS connection with your site. We manage this critical header for you at the server level for all sites. You do not need to (and cannot) add this header yourself.

Frequently Asked Questions (FAQ)

Why doesn’t Pressable enable all these security headers by default?

A: Many security headers, especially Content-Security-Policy, are not universal. They require specific configurations based on a site’s unique plugins, themes, and external services. Implementing a strict, one-size-fits-all policy would break the functionality of many sites. We provide a secure foundation and give you the tools to add stricter rules that are tailored to your specific site.

A security scan says my site is missing a header. What should I do?

A: First, identify the header and review its purpose using the links in this article. If it’s a header you can add (like Permissions-Policy), you can use the custom-redirects.php method. If the missing header is related to caching or HSTS, you can rest assured it is already being handled correctly by our platform. If you’re not sure, you can reach out to our 24/7 support team for further insight.

Can I use a security plugin to add headers instead?

A: While some plugins can add headers, we recommend the custom-redirects.php method as it is the most direct and performant solution on our platform. Many security plugins attempt to modify server configuration files (like .htaccess), a method which will not work in our NGINX environment.

If you strongly prefer to use a plugin, we recommend the Redirection plugin. Their documentation on HTTP headers can be found here.

I added a header and my site looks broken. How can I fix it?

A: This usually happens because of a misconfigured Content-Security-Policy header that is blocking necessary scripts or styles from loading. To fix this, connect to your site via SFTP or open the file in your file manager plugin, and temporarily remove (or comment out) the line you added to your custom-redirects.php file. Your site should return to normal immediately. You can then work on adjusting the policy to be less restrictive, testing your changes on a staging site before moving the working version to your live site.