Missing HTTP Security Headers Implementation Scanner

HTTP Strict Transport Security (HSTS) is a web security policy mechanism whereby a web server declares that complying user agents (such as a web browser) are to interact with it using only secure (HTTPS) connections. The HSTS Policy is communicated by the server to the user agent via a HTTP response header field named "Strict-Transport-Security". HSTS Policy specifies a period of time during which the user agent shall access the server in only secure fashion. The target website is being served from not only HTTPS but also HTTP and it lacks of HSTS policy implementation.

There is no direct impact of not implementing CSP on your website. However, if your website is vulnerable to a Cross-site Scripting attack CSP can prevent successful exploitation of that vulnerability. By not implementing CSP you’ll be missing out this extra layer of security. CSP is an added layer of security that helps to mitigate mainly Cross-site Scripting attacks.

Clickjacking is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on a framed page when they were intending to click on the top level page. Thus, the attacker is "hijacking" clicks meant for their page and routing them to other another page, most likely owned by another application, domain, or both. Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker. The X-Frame-Options HTTP header field indicates a policy that specifies whether the browser should render the transmitted resource within a frame or an iframe. Servers can declare this policy in the header of their HTTP responses to prevent clickjacking attacks, which ensures that their content is not embedded into other pages or frames.

The X-Content-Type-Options header is used to protect against MIME sniffing vulnerabilities. Upon receiving a HTTP header, the browser will check to see if the "x-content-type-options" is either "nosniff" or "sameorigin". If it is, then it will parse the response as text/html rather than its default application/octet-stream.

The X-Permitted-Cross-Domain-Policies header is used to allow PDF and Flash documents for cross-domain requests. It defines which domains are allowed to access the content of another domain, thus preventing cross-site request forgery (CSRF) attacks.

The Referrer-Policy HTTP header controls how much referrer information (sent with the Referer header) should be included with requests. It has been designed to protect users from being tracked as they browse the web, and it can be set in a browser to make various changes to the requests made from each website.

The Clear-Site-Data header allows you to clear the cache, cookies and other site data from a specific site. This is a very handy feature when you have sensitive information being cached on sites that you don't want to reveal when someone else uses your computer.

The HTTP Cross-Origin-Embedder-Policy (COEP) response header prevents a document from loading any cross-origin resources that don't explicitly grant the document permission (using CORP or CORS). This is a security header that allows sites to control who can embed content from their site into other sites.

The HTTP cross-origin-opener-policy security header can be used to prevent malicious scripts from opening data connections with remote servers. The HTTP cross-origin-opener-policy security header is technically a response header and not a request header because it's sent by the server in response to the client's request, informing them of which origins are permitted for accessing each other's resources.

The HTTP cross-origin-resource-policy can protect against several malicious attacks such as Cross-Site Scripting (XSS) and other code injection, as well as protection against unauthorized content access. The header is designed to prevent these types of attacks by providing additional restrictions on the request method and the allowable response methods.

The HTTP access-control-allow-origin header was designed to allow website developers to provide cross domain XMLHttpRequests with CORS using preflighted requests with OPTIONS requests. The Access-Control-Allow-Origin response header indicates whether the response can be shared with requesting code from the given origin.

The HTTP Access-Control-Allow-Credentials header is used to tell the browsers to expose the response to front-end JavaScript code when the request's credentials mode Request. This is a security header that is sent in the response to requests when the request method is GET, HEAD, OPTIONS, or TRACE. The value of this header can be set to either "true" or "false". When set to "true", then the browser sends credentials when making requests for cross origin resources in these methods.

The HTTP Access-Control-Expose-Headers response header allows a server to indicate which response headers should be made available to scripts running in the browser, in response to a cross-origin request.

When a browser requests a resource from a server, the server can send back one of several HTTP response headers specifying for how long the browser should cache the response. One such header is Access-Control-Max-Age which specifies that browsers should cache this response for the specified number of seconds (or minutes or hours.)

The HTTP Access-Control-Allow-Methods is used to set the methods that are allowed for access to resources on the server.

The HTTP access-control-allow-headers security header is a new security header that can be used by site owners to specify which specific headers are allowed from a given origin. This is a good way for site owners to prevent CSRF attacks and other cross-site scripting vulnerabilities that might exist on their pages.