diff --git a/files/en-us/glossary/authentication/index.md b/files/en-us/glossary/authentication/index.md index ceedf245687188b..d2faa3d1eab0b20 100644 --- a/files/en-us/glossary/authentication/index.md +++ b/files/en-us/glossary/authentication/index.md @@ -15,7 +15,7 @@ Types of authentication information, also called _authentication factors_, are c - Something the user has, such as a phone. - Something the user is, such as a thumbprint. -Multi-factor authentication (MFA) systems require the user to provide more than one factor: for example, a password combined with a one-time code sent to the user's phone. +{{glossary("Multi-factor authentication")}} (MFA) systems require the user to provide more than one factor: for example, a password combined with a one-time code sent to the user's phone. ## See also diff --git a/files/en-us/glossary/continuous_integration/index.md b/files/en-us/glossary/continuous_integration/index.md new file mode 100644 index 000000000000000..a7d5d7795609981 --- /dev/null +++ b/files/en-us/glossary/continuous_integration/index.md @@ -0,0 +1,16 @@ +--- +title: Continuous integration +slug: Glossary/Continuous_integration +page-type: glossary-definition +sidebar: glossarysidebar +--- + +Continuous integration (CI) is a software development practice in which changes to the source are frequently integrated into the main codebase. + +It's an important practice whenever a team of developers is working on a shared codebase. In this situation, different developers might be making overlapping changes to the code at the same time, each in their personal branches. Frequent integration of each developer's changes makes it much less likely that conflicts will occur, and much easier to resolve them when they do. + +As [Martin Fowler observes](https://martinfowler.com/articles/continuousIntegration.html#EveryonePushesCommitsToTheMainlineEveryDay): + +> Integration is primarily about communication. Integration allows developers to tell other developers about the changes they have made. Frequent communication allows people to know quickly as changes develop. + +A major aspect of CI is automated build and test: typically, in a CI system, as soon as a developer opens a pull request to commit their changes to the main branch, an automated process builds the product and runs tests. Once all the tests pass, the change can be peer-reviewed. diff --git a/files/en-us/glossary/multi-factor_authentication/index.md b/files/en-us/glossary/multi-factor_authentication/index.md new file mode 100644 index 000000000000000..53b86afd68780ba --- /dev/null +++ b/files/en-us/glossary/multi-factor_authentication/index.md @@ -0,0 +1,18 @@ +--- +title: Multi-factor authentication +slug: Glossary/Multi-factor_authentication +page-type: glossary-definition +sidebar: glossarysidebar +--- + +Multi-factor authentication (MFA) is an authentication method in which the user has to present more than one type of evidence to a system in order to be authenticated. + +Most commonly, three different types of evidence (or _factors_) are distinguished: + +- Something you know, such as a password or PIN +- Something you have, such as a cellphone or a hardware security token +- Something you are: a biometric such as a fingerprint + +If an authentication system requires the user to provide more than one of these factors in order to authenticate, then it is a multi-factor system. + +For example, the system might ask the user for a password as well as a code generated by the authenticator app on their phone. diff --git a/files/en-us/glossary/principle_of_least_privilege/index.md b/files/en-us/glossary/principle_of_least_privilege/index.md new file mode 100644 index 000000000000000..0dd7441ab6d28fd --- /dev/null +++ b/files/en-us/glossary/principle_of_least_privilege/index.md @@ -0,0 +1,12 @@ +--- +title: Principle of least privilege +slug: Glossary/Principle_of_least_privilege +page-type: glossary-definition +sidebar: glossarysidebar +--- + +The principle of least privilege is a design consideration in computer security, according to which entities (including users, system processes, or programs) should be granted the minimum amount of access that they need in order to do their jobs. + +For example, in a software development team, all members might need the ability to write to the source code repository, but only a subset of the team might need the ability to alter the repository's security settings. + +Applying the principle of least privilege reduces the potential damage when an entity is compromised by an attacker: so for example, if a team member's account is compromised, then the damage that the attacker can do is limited by the privileges that were granted to that team member. diff --git a/files/en-us/learn_web_development/core/frameworks_libraries/svelte_typescript/index.md b/files/en-us/learn_web_development/core/frameworks_libraries/svelte_typescript/index.md index be779bf58297e7c..5be914e219f467a 100644 --- a/files/en-us/learn_web_development/core/frameworks_libraries/svelte_typescript/index.md +++ b/files/en-us/learn_web_development/core/frameworks_libraries/svelte_typescript/index.md @@ -215,7 +215,7 @@ And if you pass something that is not a number, it will complain about it: ![Type checking in VS Code - the ms variable has been given a non-numeric value](06-vscode-type-checking-in-components.png) -The application template has a `check` script configured that runs `svelte-check` against your code. This package allows you to detect errors and warnings normally displayed by a code editor from the command line, which makes it pretty useful for running it in a continuous integration (CI) pipeline. Just run `npm run check` to check for unused CSS, and return A11y hints and TypeScript compile errors. +The application template has a `check` script configured that runs `svelte-check` against your code. This package allows you to detect errors and warnings normally displayed by a code editor from the command line, which makes it pretty useful for running it in a {{glossary("continuous integration")}} (CI) pipeline. Just run `npm run check` to check for unused CSS, and return A11y hints and TypeScript compile errors. In this case, if you run `npm run check` (either in the VS Code console or terminal) you will get the following error: diff --git a/files/en-us/learn_web_development/extensions/server-side/express_nodejs/skeleton_website/index.md b/files/en-us/learn_web_development/extensions/server-side/express_nodejs/skeleton_website/index.md index 09ff653eb87deab..9bd1c3df319119f 100644 --- a/files/en-us/learn_web_development/extensions/server-side/express_nodejs/skeleton_website/index.md +++ b/files/en-us/learn_web_development/extensions/server-side/express_nodejs/skeleton_website/index.md @@ -393,7 +393,7 @@ npm install ``` > [!NOTE] -> It is a good idea to regularly update to the latest compatible versions of your dependency libraries — this may even be done automatically or semi-automatically as part of a continuous integration setup. +> It is a good idea to regularly update to the latest compatible versions of your dependency libraries — this may even be done automatically or semi-automatically as part of a {{glossary("continuous integration")}} setup. > > Usually library updates to the minor and patch version remain compatible. > We've prefixed each version with `^` above so that we can automatically update to the latest `minor.patch` version by running: diff --git a/files/en-us/learn_web_development/extensions/testing/introduction/index.md b/files/en-us/learn_web_development/extensions/testing/introduction/index.md index c4f12efcb6ddad6..bba0fb368b460af 100644 --- a/files/en-us/learn_web_development/extensions/testing/introduction/index.md +++ b/files/en-us/learn_web_development/extensions/testing/introduction/index.md @@ -130,7 +130,7 @@ Finally, you can get smarter with your testing using auditing or automation tool - see if a button click causes something to happen successfully (like for example, a map displaying), displaying the results once the tests are completed - take a screenshot of each, allowing you to see if a layout is consistent across the different browsers. -If you wish to invest money in testing, there are also commercial tools that can automate much of the setup and testing for you (such as [Sauce Labs](https://saucelabs.com/) and [Browser Stack](https://www.browserstack.com/)). These kinds of tools usually enable a continuous integration workflow, where code changes are automatically tested before they are allowed to be submitted into your code repository. +If you wish to invest money in testing, there are also commercial tools that can automate much of the setup and testing for you (such as [Sauce Labs](https://saucelabs.com/) and [Browser Stack](https://www.browserstack.com/)). These kinds of tools usually enable a {{glossary("continuous integration")}} workflow, where code changes are automatically tested before they are allowed to be submitted into your code repository. #### Testing on prerelease browsers diff --git a/files/en-us/learn_web_development/extensions/testing/your_own_automation_environment/index.md b/files/en-us/learn_web_development/extensions/testing/your_own_automation_environment/index.md index 7b3963345bda83e..36835ee68c80a1a 100644 --- a/files/en-us/learn_web_development/extensions/testing/your_own_automation_environment/index.md +++ b/files/en-us/learn_web_development/extensions/testing/your_own_automation_environment/index.md @@ -795,7 +795,7 @@ So this is pretty cool. We have tested this locally, but you could set this up o ## Integrating Selenium with CI tools -As another point, it is also possible to integrate Selenium and related tools like LambdaTest, and Sauce Labs with continuous integration (CI) tools — this is useful, as it means you can run your tests via a CI tool, and only commit new changes to your code repository if the tests pass. +As another point, it is also possible to integrate Selenium and related tools like LambdaTest, and Sauce Labs with {{glossary("continuous integration")}} (CI) tools — this is useful, as it means you can run your tests via a CI tool, and only commit new changes to your code repository if the tests pass. It is out of scope to look at this area in detail in this article, but we'd suggest getting started with Travis CI — this is probably the easiest CI tool to get started with and has good integration with web tools like GitHub and Node. diff --git a/files/en-us/learn_web_development/getting_started/environment_setup/command_line/index.md b/files/en-us/learn_web_development/getting_started/environment_setup/command_line/index.md index cff1a17015ca6ec..04ccffef756b3ea 100644 --- a/files/en-us/learn_web_development/getting_started/environment_setup/command_line/index.md +++ b/files/en-us/learn_web_development/getting_started/environment_setup/command_line/index.md @@ -464,7 +464,7 @@ With Prettier there's a number of ways automation can be achieved and though the - Before you commit your code into a git repository using [Husky](https://github.com/typicode/husky). - Whenever you hit "save" in your code editor, be it [VS Code](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode), or [Sublime Text](https://packagecontrol.io/packages/JsPrettier). -- As part of continuous integration checks using tools like [GitHub Actions](https://github.com/features/actions). +- As part of {{glossary("continuous integration")}} checks using tools like [GitHub Actions](https://github.com/features/actions). Our personal preference is the second one — while using say VS Code, Prettier kicks in and cleans up any formatting it needs to do every time we hit save. You can find a lot more information about using Prettier in different ways in the [Prettier docs](https://prettier.io/docs/). diff --git a/files/en-us/web/accessibility/guides/information_for_web_authors/index.md b/files/en-us/web/accessibility/guides/information_for_web_authors/index.md index 00dcc8e9a66df1a..c55ac24abe01938 100644 --- a/files/en-us/web/accessibility/guides/information_for_web_authors/index.md +++ b/files/en-us/web/accessibility/guides/information_for_web_authors/index.md @@ -41,7 +41,7 @@ Tools to integrate into your build process, programmatically adding accessibilit - [Lighthouse Audits](https://github.com/GoogleChrome/lighthouse/blob/main/docs/readme.md#using-programmatically) - [AccessLint.js](https://github.com/accesslint/accesslint.js/tree/master) -Continuous integration tools to find accessibility issues in your GitHub pull requests: +{{glossary("Continuous integration")}} tools to find accessibility issues in your GitHub pull requests: - [AccessLint](https://accesslint.com/) diff --git a/files/en-us/web/api/publickeycredential/getclientcapabilities_static/index.md b/files/en-us/web/api/publickeycredential/getclientcapabilities_static/index.md index d0f3c19c329ecac..629eae8daad3936 100644 --- a/files/en-us/web/api/publickeycredential/getclientcapabilities_static/index.md +++ b/files/en-us/web/api/publickeycredential/getclientcapabilities_static/index.md @@ -37,12 +37,12 @@ The WebAuthn client capability strings are: - : The client supports usage of the [hybrid](/en-US/docs/Web/API/AuthenticatorAttestationResponse/getTransports#hybrid) transport. This means that the client can use authenticators that rely on Bluetooth, NFC, or USB. - `"passkeyPlatformAuthenticator"` - - : The client allows usage of a passkey authenticator that supports multi-factor authentication mechanisms such as a PIN or biometric check. + - : The client allows usage of a passkey authenticator that supports {{glossary("multi-factor authentication")}} mechanisms such as a PIN or biometric check. The authenticator can be part of the same platform (device) as the client, or connected via a hybrid transport such as Bluetooth or USB. The credentials are stored on the authenticator. See [Passkeys developer guide for relying parties](https://developers.google.com/identity/passkeys/developer-guides). - `userVerifyingPlatformAuthenticator` - - : The client has a platform authenticator (part of the same device) that supports multi-factor authentication mechanisms, such as a PIN or biometric check. + - : The client has a platform authenticator (part of the same device) that supports {{glossary("multi-factor authentication")}} mechanisms, such as a PIN or biometric check. The credentials may be stored on either the RP or the authenticator. - `relatedOrigins` - : The client supports [Related Origin Requests](https://web.dev/articles/webauthn-related-origin-requests). diff --git a/files/en-us/web/api/publickeycredential/isuserverifyingplatformauthenticatoravailable_static/index.md b/files/en-us/web/api/publickeycredential/isuserverifyingplatformauthenticatoravailable_static/index.md index 8cec34df9cbb6e0..feb89d8ef616ba4 100644 --- a/files/en-us/web/api/publickeycredential/isuserverifyingplatformauthenticatoravailable_static/index.md +++ b/files/en-us/web/api/publickeycredential/isuserverifyingplatformauthenticatoravailable_static/index.md @@ -10,7 +10,7 @@ browser-compat: api.PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvai The **`isUserVerifyingPlatformAuthenticatorAvailable()`** static method of the {{domxref("PublicKeyCredential")}} interface returns a {{jsxref("Promise")}} which resolves to `true` if a user-verifying platform authenticator is present. -A user-verifying platform authenticator is a kind of multi-factor authenticator that is part of the client device (it is generally not removable) and that involves an action from the user in order to identify them. Common user-verifying platform authenticators include: +A user-verifying platform authenticator is a kind of {{glossary("multi-factor authentication", "multi-factor authenticator")}} that is part of the client device (it is generally not removable) and that involves an action from the user in order to identify them. Common user-verifying platform authenticators include: - Touch ID or Face ID (macOS and iOS) - Windows Hello (Windows) diff --git a/files/en-us/web/api/web_authentication_api/index.md b/files/en-us/web/api/web_authentication_api/index.md index 88061afc2ac71b7..542d270132faab8 100644 --- a/files/en-us/web/api/web_authentication_api/index.md +++ b/files/en-us/web/api/web_authentication_api/index.md @@ -7,11 +7,11 @@ browser-compat: api.PublicKeyCredential {{securecontext_header}}{{DefaultAPISidebar("Web Authentication API")}} -The Web Authentication API (WebAuthn) is an extension of the [Credential Management API](/en-US/docs/Web/API/Credential_Management_API) that enables strong authentication with public key cryptography, enabling passwordless authentication and secure multi-factor authentication (MFA) without SMS texts. +The Web Authentication API (WebAuthn) is an extension of the [Credential Management API](/en-US/docs/Web/API/Credential_Management_API) that enables strong authentication with public key cryptography, enabling passwordless authentication and secure {{glossary("multi-factor authentication")}} (MFA) without SMS texts. ## WebAuthn concepts and usage -WebAuthn uses [asymmetric (public-key) cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography) instead of passwords or SMS texts for registering, authenticating, and [multi-factor authentication](https://en.wikipedia.org/wiki/Multi-factor_authentication) with websites. This has some benefits: +WebAuthn uses [asymmetric (public-key) cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography) instead of passwords or SMS texts for registering, authenticating, and {{glossary("multi-factor authentication")}} with websites. This has some benefits: - **Protection against phishing:** An attacker who creates a fake login website can't login as the user because the signature changes with the [origin](/en-US/docs/Glossary/Origin) of the website. - **Reduced impact of data breaches:** Developers don't need to hash the public key, and if an attacker gets access to the public key used to verify the authentication, it can't authenticate because it needs the private key. diff --git a/files/en-us/web/api/webotp_api/index.md b/files/en-us/web/api/webotp_api/index.md index 8f06c95489639a1..b2c51cd2739871e 100644 --- a/files/en-us/web/api/webotp_api/index.md +++ b/files/en-us/web/api/webotp_api/index.md @@ -23,7 +23,7 @@ Phone numbers are often used as a way to identify the user of an app. An SMS is OTP use cases include: -- Improving sign-in security by using a phone number as an extra factor (i.e., for two-factor authentication (2FA) or multifactor authentication (MFA)). +- Improving sign-in security by using a phone number as an extra factor as part of a {{glossary("multi-factor authentication")}} system. - Verifying sensitive actions such as payments. The WebOTP API allows web apps to expedite this validation process by copying the OTP from the SMS and passing it to the app automatically after the user has provided consent (most native platforms have an equivalent API). diff --git a/files/en-us/web/performance/guides/performance_budgets/index.md b/files/en-us/web/performance/guides/performance_budgets/index.md index 5bc572ecaac0051..15aef3cf78f52d6 100644 --- a/files/en-us/web/performance/guides/performance_budgets/index.md +++ b/files/en-us/web/performance/guides/performance_budgets/index.md @@ -45,7 +45,7 @@ The ultimate value of a Performance Budget is to correlate the impact of Perform During development, there are a few tools to run checks against new or modified assets: - A module bundler (e.g., [webpack](https://webpack.js.org/)), has [performance features](https://webpack.js.org/configuration/performance/) that will notify you when assets exceed specified limits. -- [Bundlesize](https://github.com/siddharthkp/bundlesize), allows you to define and run file size checks in your continuous integration (CI) pipeline. +- [Bundlesize](https://github.com/siddharthkp/bundlesize), allows you to define and run file size checks in your {{glossary("continuous integration")}} (CI) pipeline. File size checks are the first line of defense against regressions but translating size back into time metrics can be difficult since development environments could be missing 3rd party scripts, and optimizations commonly provided by a [CDN](/en-US/docs/Glossary/CDN). diff --git a/files/en-us/web/performance/guides/rum-vs-synthetic/index.md b/files/en-us/web/performance/guides/rum-vs-synthetic/index.md index ff427f2f1cb9aaf..f8a1a8aafeb26cb 100644 --- a/files/en-us/web/performance/guides/rum-vs-synthetic/index.md +++ b/files/en-us/web/performance/guides/rum-vs-synthetic/index.md @@ -16,7 +16,7 @@ An example of synthetic monitoring is [WebPageTest.org](https://www.webpagetest. Controlling for environmental variables is helpful in understanding where performance bottlenecks have been occurring and identifying the source of any performance issues. For example, but it isn't reflective of the actual experience of users, especially the long tail. -Synthetic monitoring can be an important component of regression testing and production site monitoring. Test the site at every stage of development and regularly in production. Changes from baseline performance as part of continuous integration should fail a push. If an issue arises in production, synthetic monitoring can provide insight, helping identify, isolate, and resolve problems before they negatively user experience. +Synthetic monitoring can be an important component of regression testing and production site monitoring. Test the site at every stage of development and regularly in production. Changes from baseline performance as part of {{glossary("continuous integration")}} should fail a push. If an issue arises in production, synthetic monitoring can provide insight, helping identify, isolate, and resolve problems before they negatively user experience. ## Real User Monitoring diff --git a/files/en-us/web/privacy/index.md b/files/en-us/web/privacy/index.md index 20473fcb2f8a301..9c4253afd388871 100644 --- a/files/en-us/web/privacy/index.md +++ b/files/en-us/web/privacy/index.md @@ -211,7 +211,7 @@ You need to make sure that user data is transmitted and stored securely once you The below tips offer some guidance on protecting your user's data: - Security is hard to get right. When implementing a secure solution that involves data collection — particularly if it is sensitive data such as sign-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 out your own solution for collecting user data, make sure you understand what you are doing. Hire an experienced server-side developer and/or security engineer to implement the system, and ensure it is tested thoroughly. Use multifactor authentication (MFA) to provide better protection. Consider using a dedicated API such as [Web Authentication](/en-US/docs/Web/API/Web_Authentication_API) or [Federated Credential Management](/en-US/docs/Web/API/FedCM_API) to streamline the client-side of the app. +- If you want to roll out your own solution for collecting user data, make sure you understand what you are doing. Hire an experienced server-side developer and/or security engineer to implement the system, and ensure it is tested thoroughly. Use {{glossary("multi-factor authentication")}} (MFA) to provide better protection. Consider using a dedicated API such as [Web Authentication](/en-US/docs/Web/API/Web_Authentication_API) or [Federated Credential Management](/en-US/docs/Web/API/FedCM_API) to streamline the client-side of the app. - When collecting user sign-up information, enforce strong passwords so your user's account details cannot be easily guessed. Weak passwords are one of the main causes of security breaches. Encourage your users to use a password manager to generate and store complex passwords; this way they won't worry about remembering them, or create a security risk by writing them down. - Don't include sensitive data in URLs — if a third party intercepts the URL (for example via the {{httpheader("Referer")}} header), they could steal that information. Use `POST` requests rather than `GET` requests to avoid this. - Consider using tools like [Content Security Policy](/en-US/docs/Web/HTTP/Guides/CSP) and [Permissions Policy](/en-US/docs/Web/HTTP/Guides/Permissions_Policy) to enforce a set of feature usage on your site that makes it harder to introduce vulnerabilities. Be careful when doing this — 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. This is something you can look into when auditing your third-party resources (see [Carefully manage third-party resources](#carefully_manage_third-party_resources)). diff --git a/files/en-us/web/security/attacks/index.md b/files/en-us/web/security/attacks/index.md index 55eee50043492ba..5b1ce6813cfde30 100644 --- a/files/en-us/web/security/attacks/index.md +++ b/files/en-us/web/security/attacks/index.md @@ -19,5 +19,7 @@ This page links to pages explaining how some common attacks work, and how they c - : In a cross-site scripting (XSS) attack, a website accepts some input crafted by the attacker and mistakenly includes this input in the site's own pages in a way that makes the browser execute it as code. The malicious code can then do anything that the site's own front-end code could do. - [Manipulator in the Middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) - : In a Manipulator in the Middle (MITM) attack, the attacker inserts themselves between the user's browser and the server, and can see and potentially modify any of the traffic exchanged over HTTP. +- [Supply chain attacks](/en-US/docs/Web/Security/Attacks/Supply_chain_attacks) + - : In a supply chain attack, the attacker compromises part of the site's supply chain, such as any third-party dependencies that it uses. - [Subdomain takeover](/en-US/docs/Web/Security/Attacks/Subdomain_takeover) - - : In a Subdomain takeover attack, the attacker gains control over a subdomain of a target domain. + - : In a subdomain takeover attack, the attacker gains control over a subdomain of a target domain. diff --git a/files/en-us/web/security/attacks/supply_chain_attacks/index.md b/files/en-us/web/security/attacks/supply_chain_attacks/index.md new file mode 100644 index 000000000000000..888addaa2540ee2 --- /dev/null +++ b/files/en-us/web/security/attacks/supply_chain_attacks/index.md @@ -0,0 +1,151 @@ +--- +title: Supply chain attacks +slug: Web/Security/Attacks/Supply_chain_attacks +page-type: guide +sidebar: security +--- + +A _software supply chain_ consists of all the software and tools used to create and maintain a software product. This includes not only the software developed for the product itself but all the software and tools used in its production. + +In a supply chain attack, the attacker targets part of the product's supply chain in order to compromise the product itself. + +The most obvious example here is a third-party library. If you use, for example, an [npm](https://www.npmjs.com/) package developed by a third party, it has the ability to compromise your site. It may do so deliberately, if it is malicious, or accidentally, if it contains inadvertent vulnerabilities of its own. Essentially, you have to trust your third-party dependencies as much as you trust your own code. + +Less obviously, the same principle applies to all the tools you use in creating your software, including code editors, editor plugins, version control systems, build tools, and so on. Any of these tools could insert malicious or vulnerable code into your final software product, in the course of the transformations they apply. + +In this document we'll outline practices to follow to secure your software supply chain. It's organized into two main sections: + +- [Securing your development environment](#securing_your_development_environment): practices to help ensure your own code isn't compromised. +- [Managing third-party dependencies](#managing_third-party_dependencies): practices to help ensure that your dependencies are not compromised. + +## Securing your development environment + +One route for a supply chain attack is for an attacker to introduce vulnerabilities or malicious code directly into your own product. In this section we'll describe some practices that can counter this threat. + +### Implementing access control + +Implement strong access control for everyone working on the project, including anyone with write access to your code repository or with the permissions to modify the build or testing configuration. Good practices here include: + +- Requiring {{glossary("multi-factor authentication")}} for team members. +- Following the {{glossary("principle of least privilege")}}: that is, only giving privileges to team members that need them, and actively minimizing the number of team members that are granted very powerful permissions. + +### Securing tools + +Assess the security risk of any of the tools you use in the production of your site, including: + +- Text editors and IDEs +- Editor plugins +- Source control systems +- All tools involved in your build, test, and deployment processes + +For open source software dependencies, you can use the [Concise Guide for Evaluating Open Source Software](https://best.openssf.org/Concise-Guide-for-Evaluating-Open-Source-Software), published by the [OpenSSF](https://openssf.org/), as a guide. + +### Securing your configuration + +Understand and apply secure settings for your tools, especially your source control system. Key protections are: + +- Ensuring that pull requests (PRs) go through review and explicit approval from a code owner before they can be merged. +- Ensuring that PRs pass {{glossary("continuous integration")}} checks before they can be merged. +- Requiring that commits are signed. + +See the OpenSSF's [Source Code Management Platform Configuration Best Practices](https://best.openssf.org/SCM-BestPractices/), which includes specific checklists for GitHub and GitLab. + +## Managing third-party dependencies + +Third-party dependencies include not only libraries and frameworks that your code uses, but all third-party tools involved in the development process, including editors, IDEs, source control systems, package managers, and build tools. + +To mitigate problems with third-party dependencies, we'll discuss two practices: + +1. Keeping an inventory of dependencies, and using it to monitor them for vulnerabilities. +2. Defining and following a process for adding new dependencies. +3. Using Subresource Integrity for external scripts. + +### Keeping an inventory + +To be able to manage dependencies it's obviously essential to know what they are. An inventory of software dependencies is called a _Software Bill of Materials_ (SBOM). + +Any inventory is better than none: however, using a standard format for representing an SBOM means you can: + +- Share your SBOM with third parties +- Integrate tools that can understand your SBOM for purposes such as regulatory compliance or vulnerability monitoring. + +The two most common standards for representing a software bill of materials are: + +- [CycloneDX](https://cyclonedx.org/), originally developed by [OWASP](https://owasp.org/). +- [SPDX](https://spdx.dev/), maintained by the [Linux Foundation](https://www.linuxfoundation.org/). + +Both these standards have good support, and you can use either to represent the SBOM for your project. SPDX was initially focused on helping products ensure that they are compliant with open source software licenses, but has added features to support security use cases. CycloneDX is a newer and more lightweight standard which was focused from the start on promoting supply chain security. + +#### Anatomy of an SBOM + +> [!NOTE] +> In this section we'll use CycloneDX as a concrete example of an SBOM format. +> +> This section only provides an brief introduction to some of the most fundamental parts of the CycloneDX object model. For the full details, see the CycloneDX [Authoritative Guide to SBOM](https://cyclonedx.org/guides/OWASP_CycloneDX-Authoritative-Guide-to-SBOM-en.pdf). + +In CycloneDX, all dependencies are either _components_ or _services_. + +- Components include, but are not limited to, software frameworks, libraries, applications, and configuration data. +- Services represent external APIs that software may call, for example through endpoint URIs. + +Every component and service used in the product, either directly or indirectly, is represented by an object in the SBOM. The object includes information about the item including its name, version, author, license, description, {{glossary("hash_function", "hashes")}} (for components) and endpoint URIs (for services). + +The SBOM also lists vulnerabilities that have been identified in the product's dependencies. Each item in the list contains information about this vulnerability, including a description, a set of [CWE](https://cwe.mitre.org/index.html) codes, mitigations, links to advisories, and the identifiers for the components or services that the vulnerability affects. + +#### Creating an SBOM + +You can generate an SBOM for a product using a tool such as [cdxgen](https://cyclonedx.github.io/cdxgen/#/). An SBOM is usually generated as part of the build process, although it is possible to generate one at other stages of the software lifecycle. + +#### Using an SBOM + +An SBOM enables you to implement several defenses against supply chain attacks, and we'll list three important ones here: + +- **Vulnerability management**: one of the main uses for an SBOM is to respond to vulnerabilities that have been identified in your dependencies. You can use third-party tools such as OWASP's [Dependency-Track](https://dependencytrack.org/), which automate this by scanning sources of vulnerability reports such as the [NIST National Vulnerability Database](https://nvd.nist.gov/) or [GitHub Advisories](https://github.com/advisories). +- **Integrity verification**: if the SBOM contains hashes for dependencies, it's possible to verify that the source of the component you're depending on has not been modified from its original released form. +- **Supplier risk management**: by capturing information about the supplier of your dependencies, an SBOM can help you understand when you are depending on components or services from suppliers that are no longer considered reliable. + +### Evaluating new dependencies + +Before adding any new dependencies, you should assess how much of a security risk they represent. You need to be confident that the dependency is actively maintained, that it has a record of fixing issues and a process for reporting and responding to security vulnerabilities. + +The [Concise Guide for Evaluating Open Source Software](https://best.openssf.org/Concise-Guide-for-Evaluating-Open-Source-Software), published by the [OpenSSF](https://openssf.org/), lists questions you should ask before adding a new dependency. + +### Using Subresource Integrity + +Many websites include externally hosted scripts: most notably, but not exclusively, scripts that are served from a {{glossary("CDN", "Content Delivery Network (CDN)")}}: + +```html + +``` + +This represents a risk to your supply chain: if an attacker can get control of the `cdn.example.org` domain, they can replace the script with a malicious script, and thus compromise your site. + +External scripts, like other software dependencies, should be part of your SBOM, but an additional defense is to set the script's [`integrity`](/en-US/docs/Web/HTML/Reference/Elements/script#integrity) attribute: + +```html + +``` + +The value of this attribute contains a {{glossary("hash_function", "cryptographic hash")}} of the script's contents. If the script has been modified by an attacker, then the browser will refuse to load it, and you will be protected. + +This does add an extra maintenance burden: every time the source changes (for example, every time a new version is released) you must update the attribute's value in your code. + +The {{htmlelement("link")}} element also supports the `integrity` attribute, so you can (and should) use it for CSS stylesheets as well as scripts. + +See [Subresource Integrity](/en-US/docs/Web/Security/Subresource_Integrity) for more details. + +## Defense summary checklist + +- Require {{glossary("multi-factor authentication")}} for team members and minimize permissions granted. +- Assess tools involved in your build, test, and deployment processes +- Ensure pull requests go through review and pass {{glossary("continuous integration")}} checks +- Keep an inventory (SBOM) of dependencies +- Define a process for managing, updating, monitoring dependencies +- Use Subresource Integrity for externally referenced scripts and stylesheets +- Lock dependency versions (`package-lock.json`) + +## See also + +- [Software Supply Chain Security](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html) at [owasp.org](https://owasp.org/) diff --git a/files/en-us/web/security/index.md b/files/en-us/web/security/index.md index a52e96918e3d11f..8095a5dfb4b0684 100644 --- a/files/en-us/web/security/index.md +++ b/files/en-us/web/security/index.md @@ -94,7 +94,7 @@ You should prepare for the removal of cross-site cookies by limiting the amount 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. 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](/en-US/docs/Web/API/Web_Authentication_API) or [Federated Credential Management](/en-US/docs/Web/API/FedCM_API) to streamline the client-side of the app. +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 {{glossary("multi-factor authentication")}} (MFA) to provide better protection. Consider using a dedicated API such as [Web Authentication](/en-US/docs/Web/API/Web_Authentication_API) or [Federated Credential Management](/en-US/docs/Web/API/FedCM_API) to streamline the client-side of the app. Here are some other tips for providing secure logins: