How to Configure HTTP Security Headers on WordPress | Shield Security

HTTP security headers are lines of code that users can add to the headers of an HTTP response. These headers provide an extra layer of security for your website by helping to protect against various types of attacks, such as cross-site scripting (XSS), clickjacking, and content sniffing. HTTP security headers instruct browsers on how to behave when handling a site’s content, which helps in mitigating certain types of attacks and vulnerabilities. Configuring these headers is an essential step in keeping your WordPress website safe. By implementing these headers, you can significantly reduce the risk of common web vulnerabilities and protect your site’s visitors from potential threats . A rundown of HTTP headers and what they do Let’s look into the specific HTTP header options offered by Shield Security PRO and their impact on your site’s defences. Content-Security-Policy (CSP) Content-Security-Policy fortifies web page security. By restricting the loading of resources like JavaScript and images, it mitigates potential threats. Shield Security PRO simplifies this intricate security tool, allowing users to set custom content-security-policy rules within the plugin. Block iFrames iFrames, HTML documents embedded within others, can pose security risks when misused. Shield Security PRO allows users to control iFrame behaviour in the following ways: Allow all iFrame requests. Allow requests only from the same domain. Block all iFrame requests, preventing content from appearing on external web pages. XSS Protection Cross-Site Scripting (XSS) is a security vulnerability where hackers run code through a browser, accessing sensitive information. Shield Security Pro’s XSS Protection Security Header directs browsers to block potential Reflective XSS attacks, enhancing default browser protections. Prevent Mime-Sniff Mime-sniffing is a preventive measure against malicious content by verifying MIME types. Users can toggle this header on and off using Shield Security PRO’s HTTP header settings, offering flexibility in content scrutiny. Referrer Policy HTTP Referrers allow websites to identify the source of a requested resource, aiding in understanding the origin of each request. Shield Security PRO recognizes the significance of the Referrer Policy in reinforcing web security and provides users with adjustable settings, even without extensive coding knowledge. Understanding the Referrer Policy helps to refine your website’s security posture. This setting controls the information shared with other sites when users navigate various pages. Referrer policy options are: Option What is it? Default: Full Referrer URL The browser always sends the full URL with any request to any origin. (Directive: unsafe -url) No Referrer Instructs the browser to never send the Referrer Header with requests made from your site, including links to your own pages. (Directive: no-referrer) No Referrer When Downgrade The browser doesn’t send the Referrer Header when navigating from HTTPS to HTTP but sends the full URL when navigating from HTTP to any origin. (Directive: no-referrer- when -downgrade) Same Origin Sends the full URL if it’s the same domain; strips the value if going to another website. (Directive: same-origin) Strict Origin The browser sets the Referrer Header to the origin from which the request was made, sending the domain for HTTPS > HTTPS and HTTP > HTTP but not HTTPS > HTTP. (Directive: strict -origin) Origin When Cross-Origin Sends the full URL when on the same domain but only the domain when passing to another website. (Directive: origin-when-cross-origin) Strict Origin When Cross-Origin Sends the full URL if on the same domain and from one secure page to another, doesn’t pass if going from a secure domain to an insecure one. (Directive: strict-origin-when-cross-origin) Empty Header Indicates that the site doesn’t want to set a Referrer Policy here, falling back to a Referrer Policy defined elsewhere. (Directive: Referrer-Policy) Don’t Send This Header The browser refrains from sending the Referrer Header. ⚠️ Remember: If you have little coding experience, it is safer to contact a professional to help you with this. We will go into this in more detail later in the article.  Configuring HTTP headers manually Securing your WordPress site involves attention to HTTP headers, and while plugins simplify the process, manual configuration offers a more hands-on approach. You’ll need to edit your server configuration files or utilise WordPress’s functions.php file. The right approach depends on the web server you’re using (like Apache or Nginx) and your comfort level with editing code.  Here’s a step-by-step guide on manually setting up HTTP security headers on an Apache server: 1. Access your web server You can do this using one of these three methods: FTP/SFTP: Use an FTP client like FileZilla. You’ll need FTP credentials (host, username, and password), usually provided by your hosting provider. Hosting control panel: Access your web hosting account and navigate to the control panel, which could be cPanel, Plesk, or custom dashboards provided by the host. Look for a file manager tool or something similar so you can access and edit the files on your server. SSH access: For advanced users on a Unix-based operating system (such as macOS and Linux), securely connect via the command line using the following command. These systems come with an SSH client pre-installed. ssh username@your_server_ip

If you’re using Windows, you can use clients like PuTTY or the built-in Windows SSH client (available in Windows 10 and later). 2. Locate the .htaccess File Once you access your server files, navigate to the root directory of your WordPress installation. This is often in a directory named public_html, www, htdocs, or similar. .htaccess is the configuration file for Apache web servers, and you’ll find it in your WordPress root directory. 3. Back up .htaccess Before editing, create a backup copy to avoid potential issues. This way, if something goes wrong, you can restore your site to its previous state. 4. Edit .htaccess If you’re using your hosting provider’s file manager, you can usually click on the .htaccess file and select an option to edit. If you’re using an FTP client, you’ll need to download the file to your local machine and then open it with a text editor like Notepad++ (Windows), TextEdit (macOS), or another preferred text editor. If you’re using SSH, you can use the command-line text editor. 5. Adding HTTP Headers To keep your headers organised, we recommend you add the following lines of code for each header at the top or at the bottom of your .htaccess . Content-Security-Policy (CSP) Header set Content-Security-Policy ” default-src ‘self’; script-src ‘self’; img-src ‘self’;”

This header allows scripts from your own domain (‘self’) and It also allows images from your own domain (‘self’) and X-Content-Type-Options Header set X-Content-Type-Options “nosniff”

The value “nosniff” tells the browser not to try and guess (“sniff”) the MIME type. Instead, it should strictly adhere to the MIME type declared in the Content-Type header sent by the server. For example, if a website allows users to upload content, a user might upload a malicious script disguised as an innocent file type (like an image). If the browser incorrectly “sniffs” this script as executable (e.g., text/javascript), it might execute it, leading to potential attacks like Cross-Site Scripting (XSS). X-Frame-Options Header set X-Frame-Options “SAMEORIGIN”

When you set X-Frame-Options to “SAMEORIGIN”, you’re instructing the browser to only allow framing of your content if the parent (the site attempting to embed your site) is of the same origin. The “origin” is defined by the scheme (http, https), host (domain), and port of the URL. Banking websites often use this header to ensure that external websites can’t frame their webpages. This practice prevents attackers from overlaying malicious frames on top of banking interfaces to deceive users into revealing confidential information or inadvertently authorising transactions. Here’s another way to configure the X-Frame-Options header: Header always set X-Frame-Options “DENY”

This setting completely prohibits any website (including the same site that hosts the content) from framing the content. When set to “DENY”, no page, regardless of its origin, can embed the content within a ,