Category: Security Headers

Security headers are a powerful way to strengthen SSL and to further secure the connection between site visitors and the webserver. Security Headers can be considered ‘instructions’ for the webbrowser. For example, the X-Frame-Options header will tell the browser if the page or site is allowed to be loaded in an iFrame. We will discuss possible and recommended configurations for the four Recommended Security Headers within Really Simple SSL Pro: The Recommended Recurity Headers block within Really Simple SSL Pro

To enable a Content Security Policy in Really Simple Security Pro, start by navigating to Security -> Settings (in the top menu bar) -> Security Headers -> Content Security Policy.  Getting started with the Content Security Policy #1: Upgrade-Insecure-Requests If your site is working correctly over SSL/HTTPS, you should enable the “Upgrade Insecure Requests” slider to ensure that all requests made to your site are performed over HTTPS (even if their links do not explicitly specify “https://“). #2: Frame Ancestors

The permissions policy controls which browser features can be used on your website. This is true for both your own content, or embedded content. If you do not use certain browser features, it is strongly advised to fully disallow these features.  NB. The Geolocation API can still be used in some instances whereby a map is embedded a geolocation is used to center the map for example. Please make sure you test your website afterwards. Which option to choose? For

One of the best-known policies is the HTTP Strict Transport Security. Below, we will give a quick overview of HSTS configuration and what is recommended. If you want to know what HSTS is or why you need it: What is HSTS? Why do you need HSTS? Configuring HTTP Strict Transport Security The most effective way to use HSTS is by preloading the strict policy directly in supported browsers.  If you do not preload your website, the browser will only remember

The different Cross-Origin headers supported by Really Simple SSL are: CORP: Cross-Origin Resource Policy (same-site | same-origin | cross-origin) COEP: Cross-Origin Embedder Policy (unsafe-none | require-corp) COOP: Cross-Origin Opener Policy (unsafe-none| same-origin-allow-popups | same-origin) Practical usage in WordPress A quick decision tree for these headers is as follows: CORP: Your site is used as a resource on other websites => yes, third party websites=> CORP set to cross-origin. yes, but only your own subdomains=> CORP set to same-site no=>CORP set