Websites contain several different types of information. Some of it is non-sensitive, for example the copy shown on the public pages. Some of it is sensitive, for example customer usernames, passwords, and banking information, or internal algorithms and private product information.
Sensitive information needs to be protected, and that is the focus of web security. If that information fell into the wrong hands, it could be used to:
- Put companies at a competitive disadvantage by sharing their information with competitors.
- Disable or hijack their services, again causing serious problems with their operation.
- Put their customer's privacy at risk, making them vulnerable to profiling, targeting, loss of data, identity theft, or even financial loss.
Modern browsers already have several features to protect users' security on the web, but developers also need to employ best practices and code carefully to ensure that their websites are secure. Even simple bugs in your code can result in vulnerabilities that bad people can exploit to steal data and gain control over services for which they don't have authorization.
This article provides an introduction to web security, including information that will help you understand the aspects that can make websites vulnerable and how to secure them.
Security and privacy are distinct topics, but they are also closely-related. It is worth knowing the difference between the two and how they relate.
- Security is the act of keeping private data and systems protected against unauthorized access. This includes both company (internal) data and user and partner (external) data.
Web browsers have a strict security model that enforces a good level of fundamental content, connection, and transport security. This section looks at the basics.
Same-origin policy is a fundamental security mechanism of the web that restricts how a document or script loaded from one origin can interact with a resource from another origin. It helps isolate potentially malicious documents, reducing possible attack vectors.
In general, documents from one origin cannot make requests to other origins. This makes sense because you don't want sites to be able to interfere with one another and access things they shouldn't. It does make sense to relax this restriction in some circumstances; for example, you might have multiple sites that interact with each other, and you may want these sites to request resources from one another, such as using
This can be permitted using Cross-Origin Resource Sharing (CORS), an HTTP-header-based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources.
HTTP protocol is used by web browsers and servers to communicate with one another, request resources, provide responses (for example, providing the requested resource or detailing why the request failed), and provide security features for that communication.
Transport Layer Security (TLS) provides security and privacy by encrypting data during transport over the network and is the technology behind the HTTPS protocol. TLS is good for privacy because it stops third parties from being able to intercept transmitted data and use it maliciously.
All browsers are moving towards requiring HTTPS by default; this is practically the case already because you can't do much on the web without this protocol.
- Transport layer security (TLS)
The Transport Layer Security (TLS) protocol is the standard for enabling two networked applications or devices to exchange information privately and robustly. Applications that use TLS can choose their security parameters, which can have a substantial impact on the security and reliability of data. This article provides an overview of TLS and the kinds of decisions you need to make when securing your content.
- HTTP Strict-Transport-Security
Strict-Transport-Security:HTTP header lets a website specify that it may only be accessed using HTTPS.
- Certificate Transparency
Certificate Transparency is an open framework designed to protect against and monitor for certificate misissuances. Newly issued certificates are 'logged' to publicly run, often independent CT logs which maintain an append-only, cryptographically assured record of issued TLS certificates.
- Mixed content
An HTTPS page that includes content fetched using cleartext HTTP is called a mixed content page. Pages like this are only partially encrypted, leaving the unencrypted content accessible to sniffers and man-in-the-middle attackers.
- How to fix a website with blocked mixed content
If your website delivers HTTPS pages, all active mixed content delivered via HTTP on these pages will be blocked by default. Consequently, your website may appear broken to users (if iframes or plugins don't load, etc.). Passive mixed content is displayed by default, but users can set a preference to block this type of content, as well. This page explains what you should be aware of as a web developer.
- Weak signature algorithms
The strength of the hash algorithm used in signing a digital certificate is a critical element of the security of the certificate. This article provides some information about signature algorithms known to be weak, so you can avoid them when appropriate.
Browsers control usage of several "powerful features" in a few different ways. By "powerful features", we mean things like a site generating system notifications, using a user's web cam to get access to a media stream, manipulating the system GPU, and using web payments. If a site could just use the APIs that control such features without restriction, malicious developers could for example:
- Annoy users with unneeded notifications and other UI features.
- Clog up their browser/system to create Denial of Service (DoS) attacks.
- Steal data or money.
Such browser features are controlled as follows:
First, usage of such features is permitted only in secure contexts. A secure context is a
window or a
worker for which there is reasonable confidence that the content has been delivered securely (via HTTPS/TLS). In a secure context, the potential for communication with contexts that are not secure is limited. Secure contexts also help to prevent man-in-the-middle attackers from accessing the powerful APIs of the browser.
Note: See also Features restricted to secure contexts. This reference lists web platform features available only in secure contexts.
Second, the usage of these features is gated behind a system of user permissions — users have to explicitly opt-in to providing access to such features, meaning that these featured can't be used automatically. The user permission requests happen automatically, but you can query the state of an API permission by using the Permissions API.
Third, many other browser features can be used only in response to a user action such as clicking a button, meaning that they need to be invoked from inside an appropriate event handler. This is often called transient activation. See Features gated by user activation for more information.
There are many aspects of web security that need to be thought about on the server- and client-side. The sections below focus mainly on client-side security considerations. You can find a useful summary of security from a server-side perspective, which also includes descriptions of common attacks to watch out for, at Website security (part of our Server-side website programming learning module).
Handling data responsibly is largely concerned with cutting down on cookie usage and being careful about the data you store in them. Traditionally, web developers have used cookies to store all kinds of data, for all kinds of purposes, and it has been easy for attackers to exploit this tendency. As a result, browsers have started to limit what you can do with cross-site cookies, with the aim of removing access to them altogether in the future.
You should prepare for the removal of cross-site cookies by limiting the amount of tracking activities you rely on and/or by implementing desired information persistence in other ways.
- Use an alternative client-side storage mechanism such as the Web Storage API to persist data. Web storage does have the downside that the data is stored per-origin, so it can't be shared. Note that web storage has two variants —
localStorage. We would recommend using
sessionStoragefor extra security, as data only persists for the lifetime of the window or tab it exists in.
localStoragedata persists even after the window or tab is closed and reopened. This means that there is a higher chance of it falling into the wrong hands, for example on a shared workstation.
- Use a technology such as IFrame credentialless, First-party sets and/or the Storage Access API to allow your sites to opt-in to using cross-site cookies in a safe and controlled way or block them altogether. These technologies currently have limited browser support.
- Use a server-side solution for data persistence.
When implementing a secure solution that involves data collection, particularly if the data is sensitive such as log-in credentials, it makes sense to use a reputable solution from a well-respected provider. For example, any respectable server-side framework will have built-in features to protect against common vulnerabilities. You could also consider using a specialized product for your purpose, for example an identity provider solution or a secure online survey provider.
If you want to roll your own solution for collecting user data, make sure you understand all aspects and requirements. Hire an experienced server-side developer and/or security engineer to implement the system, and ensure it is tested thoroughly. Use multi-factor authentication (MFA) to provide better protection. Consider using a dedicated API such as Web Authentication or Federated Credential Management to streamline the client-side of the app.
Here are some other tips for providing secure logins:
- When collecting user login information, enforce strong passwords so that your user's account details cannot be easily guessed. Weak passwords are one of the main causes of security breaches. In addition, encourage your users to use a password manager so that they can use more complex passwords, don't need to worry about remembering them, and won't create a security risk by writing them down. See also our article on Insecure passwords.
- You should also educate your users about phishing. Phishing is the act of sending a message to a user (for example, an email or an SMS) containing a link to a site that looks like a site they use every day but isn't. The link is accompanied by a message designed to trick users into entering their username and password on the site so it can be stolen and then used by an attacker for malicious purposes.
Note: Some phishing sites can be very sophisticated and hard to distinguish from a real website. You should therefore educate your users to not trust random links in emails and SMS messages. If they receive a message along the lines of "Urgent, you need to log in now to resolve an issue", they should go to the site directly in a new tab and try logging in directly rather than clicking the link in the message. Or they could phone or email you to discuss the message they received.
- Protect against brute force attacks on login pages with rate limiting, account lockouts after a certain number of unsuccessful attempts, and CAPTCHA challenges.
- Manage user login sessions with unique session IDs, and automatically log out users after periods of inactivity.
As a general rule you shouldn't include sensitive data in URL query strings: if a third party intercepts the URL (for example via the
Referer HTTP header), they could steal that information. Even more serious is that these URLs can be indexed by public web crawlers, HTTP proxies, and archiving tools such as the internet archive, meaning that your sensitive data can persist on publicly accessible resources.
POST requests rather than
GET requests to avoid these issues. Our article Referer header policy: Privacy and security concerns describes in more detail the privacy and security risks associated with the
Referer header, and offers advice on mitigating those risks.
CSP allows you to add a layer of security by, for example, allowing images or scripts to be loaded only from specific trusted origins. This helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks involve a range of malicious activities, including data theft, site defacement, and distribution of malware.
Permissions policy works in a similar way, except that it is more concerned with allowing or blocking access to specific "powerful features" (as mentioned earlier).
Note: Such policies are very useful to help keep sites secure, especially when you are using a lot of third party code on your site. However, keep in mind that if you block usage of a feature that a third-party script relies on to work, you may end up breaking your site's functionality.
Following on from the previous section, when you do allow feature and resource usage on your site, you should try to ensure that resources have not been tampered with.
- Subresource integrity
Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched resource must match.
- HTTP Access-Control-Allow-Origin
Access-Control-Allow-Originresponse header indicates whether the response can be shared with requesting code from the given origin.
- HTTP X-Content-Type-Options
X-Content-Type-Optionsresponse HTTP header is a marker used by the server to indicate that the MIME types advertised in the
Content-Typeheaders should not be changed and be followed. This is a way to opt out of MIME type sniffing, or, in other words, to say that the MIME types are deliberately configured.
To protect against this, you should thoroughly sanitize data entered into your forms:
- You should implement client-side validation to inform users when they have entered data in the wrong format. You can do this using built-in HTML form validation features, or you can write your own validation code. See Client-side form validation for more information.
- You should use output encoding when displaying user input in an application UI to safely display data exactly as a user typed it in, to avoid it being executed as code. See Output encoding for more information.
Any reputable server-side framework will provide functionality for validating form submissions. In addition, a common best practice is to escape any special characters that form part of executable syntax, thereby making any entered code no longer executable and treated as plain text.
In clickjacking, a user is fooled into clicking on a UI element that performs an action different from what the user expects. This can be a risk inherent in embedded third-party content (make sure you trust what is being embedded into your site), and it can also be combined with phishing.
The following features can help guard against clickjacking:
- HTTP X-Frame-Options
X-Frame-OptionsHTTP response header can be used to indicate whether a browser should be allowed to render a page in a
<object>. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.
- CSP: frame-ancestors