Enable security headers

Check your Application Security Headers

You can check your application security headers on our service MyHeaders.


Modern web browsers offer a lot of security features aimed at protecting your users from a wide variety of threats. Security headers need to be enabled in your web application.

Sqreen can enable HTTP security headers in your web application in order to protect it against different kinds of attacks or abuses, such as cross-site scripting attacks, click-jacking attacks and content injections.

More technical details can be found on Open Web Application Security Project.

Screen Shot 2017-05-31 at 14.22.05.png

Enable your security headers in 1 click

Sqreen can enable Security Headers in your application in just 1 click. You can enable/disable those headers anytime in your different apps.


XSS Protection

Cross-site scripting (XSS) is one of the most common and dangerous type attacks on the web, as it is often used to inject malicious code into your app to extract data about a logged in user, or take advantage of their user privileges to perform actions not available by default. Setting the X-XSS-Protection header allows modern browsers to block attackers from Reflected XSS attacks.

Click jacking protection (X-Frame-Options)

Setting an X-Frame-Options header in your application protects it from someone creating a wrapper around your site doing whatever they want and displaying your page in an iframe. This allows attackers to force your users to click on some part of your website, while hidden in an iframe (these are known as clickjacking attacks). You can either choose to completely block rendering your site inside a frame by setting this header to DENY, allow it to be rendered by other pages on the same server with SAMEORIGIN or, you can specify a list of whitelisted domains with ALLOW-FROM.

MIME sniffing Protection (Mime-Content-Type)

Some browsers guess the type of file being transferred by default. This allows the browser to render an HTML file if the content looks right even if the server says that the file is plaintext. This can be used as an attack vector for untrusted JavaScript code. Setting the X-Content-Type-Options header to nosniff forces browsers to respect the server specified file type.

Coming soon...

Our team is currently qualifying new security headers - that will be available soon. Please check our change log regularly to be notified about new features.


Content Security Policy

Content Security Policy takes a little bit of effort to implement. A Content Security Policy (CSP) header lists all authorized domains and resources your app is allowed to use. Thus if a user loads a page where an attacker has injected a malicious resource, the browser will load your page, but prevent the attacker’s resource from loading. One side effect of using this header is that if you add new assets to your application, you will need to update your Content Security Policy accordingly. You can read more about CSP in this post.

HTTP Strict Transport Security

Strict Transport Security tells browsers to refuse to connect to this website as HTTP, which prevents connections from insecure locations to be downgraded from HTTPS to HTTP by an attacker. If the initial connection to a website is made over HTTP and redirected to HTTPS, the HSTS header will force further connections initiated by the user to only go through HTTPS.

Public Key Pinning Extension for HTTP

Public Key Pinning Extension for HTTP is another header that is only useful for sites running on HTTPS. While this header won’t do anything the first time, a user loads your site it will register the certificate your site is using, preventing your user’s browser from connecting to a malicious server with a different certificate that is pretending to be your website. This can be especially useful to protect your users against attackers who can create certificates for any domain (e.g. from abusing a trusted Certificate Authority or finding an HTTPS flaw).

If you’re using cookies to store session or authentication information to keep users logged into your site, there are a couple of tricks to improve your security. Two directives protect you from attackers from reading cookies in different places: HttpOnly forbids JavaScript from accessing cookies which will prevent an XSS attack from being able to send your user’s cookies to the attacker. Secure only allows the cookies to be transferred over an HTTPS connection and not over HTTP, so an attacker with access to your network won’t be able to read unencrypted cookies.