Web Security Best Practices

All pages should use HTTPS to prevent attacks and protect the privacy of your visitors. When a browser loads a URL via HTTP, the data is sent unprotected: attackers can read and modify all data being sent without anyone knowing. Attackers can steal passwords and personal information, inject malware and ads into pages, redirect visitors to malicious sites and more. HTTPS adds encryption to the data sent between your website and browsers to stop attackers from reading or tampering with communications. How you enable HTTPS is specific to the server or hosting service you’re using. Once set up, you should make sure all http:// page requests are redirected to https:// URLs.

HTTPS pages should not include HTTP resources to prevent “mixed content” browser security warnings. Page resources such as JavaScript, images, CSS and iframes that aren’t secured with HTTPS can be tampered with which can allow attackers to compromise otherwise secure HTTPS pages. For example, if attackers could modify a JavaScript file as it is being sent to a browser, they could inject code to steal passwords or redirect users to a malicious site. To prevent this, browsers block HTTP resources from loading on HTTPS pages and will show visitors what are called “mixed content” security warnings. To avoid these problems, make sure all page resources are included using https:// URLs.

Password fields in forms should be sent securely by using POST requests via HTTPS. When a password is submitted from a form on a page to your server, several steps must be taken to send the password securely. Firstly, a page with a password field should be served via HTTPS URLs to stop attackers modifying the page to send the password to wherever they want. Secondly, the form action attribute that says where the form submission is sent should be set to an HTTPS URL (<form action="https://…) so an attacker cannot observe the password in transit. Lastly, the form method attribute that sets the request method to use should be set to the POST method (<form method="POST"…). This prevents passwords being visible in browser histories, browser address bars, server logs and in the Referer request header that is sent when navigating to other sites.

Configure HSTS (HTTP Strict Transport Security) response headers to force browsers to always use HTTPS instead of HTTP on your site. When a browser visits your site and sees the Strict-Transport-Security response header, it tells the browser to transform all future http:// URL requests to your site into https:// requests. The header can include these options: 1) max-age=<seconds> says how many seconds the HSTS policy should be followed for 2) includeSubDomains says to apply the policy to all subdomains. For example, Strict-Transport-Security: max-age=31536000; includeSubDomains tells browsers to use HTTPS for the next year and for all subdomains. Warning: Start with a low max-age until you’re confident you can manage the HTTPS configuration of your site. If there are problems loading pages over HTTPS later, users will be locked out of accessing your site until the problems are fixed.

Turn off browser content sniffing to protect against content sniffing exploits. When processing a response, browsers sometimes ignore the MIME type in the Content-Type header and guess the type based on the contents of the response. This is called content sniffing and is done to improve the user experience when Content-Type headers are inaccurate or missing. However, this behaviour can be exploited. For example, if your site allows users to share images, an attacker might be able to upload a specially crafted image file that contains JavaScript code. A browser performing content sniffing might then be tricked into executing the malicious file. To reduce content sniffing attacks, set the X-Content-Type-Options response header to nosniff. This tells browsers to avoid guessing response types and to rely only on the Content-Type header.

All responses should accurately specify their MIME type so that browsers don’t have to rely on content sniffing. When the X-Content-Type-Options: nosniff response header is used to disable content sniffing, browsers rely on the Content-Type header to determine the type of each response. To avoid issues, set the Content-Type header of all responses to an accurate MIME type.

Protect against clickjacking attacks by restricting how your pages can be embedded within iframes. Clickjacking attacks involve an attacker displaying your pages within an iframe on a site they control. For example, an attacker could overlay a UI layer over an iframe to trick visitors into triggering actions on your page as well overlaying form fields to steal data. Clickjacking has been used to exploit users into sharing links on social networks, clicking ads and stealing passwords. Protect against these attacks using the X-Frame-Options response header to restrict which hosts are allowed to embed your pages. The possible options are 1) DENY to restricts all URLs 2) SAMEORIGIN to allow only URLs from the same origin as your page 3) ALLOW-FROM to allow from a specific origin. For example, X-Frame-Options: DENY will block all iframe usage. You should use a setting that’s as restrictive as possible.

Protect against XSS attacks by enabling browser XSS safeguards. XSS attacks involve an attacker injecting code into a page that is being sent to users. Some browsers have built-in XSS protection that is enabled by adding X-XSS-Protection: 1; mode=block to the response header of each page. This setting will stop the page being rendered if the browser detects an XSS attack. Note that this should only be considered as a last resort defence against XSS attacks. Your site should be thoroughly reviewed and built with XSS safeguards in mind to prevent injection attempts from ever reaching the browser.