From a16b2af2cde0bd47746dc6c0943d0f952e2fb6dd Mon Sep 17 00:00:00 2001 From: David Sint Date: Wed, 21 Jun 2023 16:51:55 +0100 Subject: [PATCH 1/8] Security Initial Commit --- docs/security/security.md | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 docs/security/security.md diff --git a/docs/security/security.md b/docs/security/security.md new file mode 100644 index 0000000..2c0c80c --- /dev/null +++ b/docs/security/security.md @@ -0,0 +1,3 @@ +# Security + +## Overview From 2bfed356f26e3916cf3d9c1ce1f473cd7892d2c5 Mon Sep 17 00:00:00 2001 From: David Sint Date: Wed, 21 Jun 2023 23:14:12 +0100 Subject: [PATCH 2/8] Include headings and basic details I've started with a basic outline for topics I think are important and given some of them the basis of guidance, or some bullet points of topics that can be expanded on later. --- docs/security/security.md | 68 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) diff --git a/docs/security/security.md b/docs/security/security.md index 2c0c80c..e3d90d9 100644 --- a/docs/security/security.md +++ b/docs/security/security.md @@ -1,3 +1,71 @@ # Security ## Overview +Security is strongest from conscious design at the outset, rather than retroactively trying to fill gaps after a solution has been built. In this respect, security should be considered at every stage of the applications lifecycle. + +A [threat model](https://www.ibm.com/garage/method/practices/code/threat-modeling/) should be considered based on the attack surface that the Web Application creates. A public-facing web application for highly confidential personal data will have a very different threat model to an internal web application that doesn't contain sensitive data nor control anything of value. + +This section focuses on some of the common security threats to defend against and mitigation techniques to utilise from the `team`'s experience building web applications. + +--- + +## Guidance + +The consensus of the most critical security risks is codified by the Open Worldwide Application Security Project (OWASP) in the [OWASP Top Ten](https://owasp.org/www-project-top-ten/). This is the starting point for the `team` when considering attack vectors in a web application's threat model. + +### Coding best security practices +- Do we need to copy [this](https://github.com/nodeshift/nodejs-reference-architecture/blob/main/docs/development/secure-development-process.md#managing-access-and-content-of-public-and-private-data-stores) [content](https://github.com/nodeshift/nodejs-reference-architecture/blob/main/docs/development/secure-development-process.md#writing-defensive-code) +- Moving secrets to backend - secrets should not be exposed to the client-side +- Bot detection - e.g. CAPTCHA + +### Encrypted Data & Traffic + +- HTTPS +- WSS +- SSL/TLS +- Client-side storage of sensitive data +- `private` cache-control +- ... + +### Authentication & Authorization + +Broken access control was the top security risk in the 2021 OWASP top ten. The two steps that are required for successful access control are authentication (verifying identity), and authorization (verify permission). + +- Cookies (including HTTP only) +- Token handling and storage e.g. JWTs +- Protecting routes on client-side routing (SPAs) + +### Cross Site Attacks + +#### Cross-Site Scripting (XSS) + +#### Cross-Site Request Forgery (CSRF) + +#### Cross-Origin Resource Sharing (CORS) + +### Security Headers + +The following are response headers that the `team` use to protect web applications. They should be configured with policies according to the web app's usage and threat model. + +- `Content-Security-Policy` to declare a policy for trusted application sources from which the browser can load resources such as scripts, stylesheets, images, fonts, etc. +- `X-Frame-Options` to declare whether the web app can be placed into an iframe on another domain +- `Strict-Transport-Security` to declare that the website requires HTTPS for encrypted subsequent requests +- `Referrer-Policy` to control what, if any information is included in the `Referer` header for network requests +- `X-Content-Type-Options` to prevent MIME sniffing attacks and force the declared content type instead of allowing a browser to interpret it, leaving room for malicious manipulation + +### Secure deployment + +- Do we need to copy https://github.com/nodeshift/nodejs-reference-architecture/blob/main/docs/development/secure-development-process.md#maintaining-a-secure-and-up-to-date-foundation-for-deployed-applications? + +### Dependency Management + +- Keeping deps up to date +- Preventing Supply Chain attacks +- Vulnerability audits + +### Security testing & monitoring + +- Pen testing +- Fuzzing +- SAST/DAST +- Active monitoring & incident response From 3139051c9667765bbeca727d8a8aaca2178b55f4 Mon Sep 17 00:00:00 2001 From: David Sint <44842045+DavidSint@users.noreply.github.com> Date: Thu, 22 Jun 2023 09:20:07 +0100 Subject: [PATCH 3/8] Include SPbD ref I mentioned the practice, but did not realise it has a term. This commit includes the feedback from @ctcpip to reference the practice --- docs/security/security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/security/security.md b/docs/security/security.md index e3d90d9..971f443 100644 --- a/docs/security/security.md +++ b/docs/security/security.md @@ -1,7 +1,7 @@ # Security ## Overview -Security is strongest from conscious design at the outset, rather than retroactively trying to fill gaps after a solution has been built. In this respect, security should be considered at every stage of the applications lifecycle. +Security is strongest from conscious design at the outset, rather than retroactively filling gaps after a solution has been built. In this respect, security should be considered at every stage of the application's lifecycle. IBM & RedHat call this practice [Security and Privacy by Design (SPbD)](https://www.redbooks.ibm.com/abstracts/redp4641.html) and recommend it for all systems, including web applications. A [threat model](https://www.ibm.com/garage/method/practices/code/threat-modeling/) should be considered based on the attack surface that the Web Application creates. A public-facing web application for highly confidential personal data will have a very different threat model to an internal web application that doesn't contain sensitive data nor control anything of value. From bad96b60d1e3843c1e956435d7deb8ee88edf6c6 Mon Sep 17 00:00:00 2001 From: ctcpip Date: Wed, 21 Jun 2023 10:50:19 -0500 Subject: [PATCH 4/8] =?UTF-8?q?=E2=9C=A8=20add=20lint=20config=20and=20wor?= =?UTF-8?q?kflow?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .editorconfig | 13 +++++++++++++ .github/workflows/lint.yml | 15 +++++++++++++++ .gitignore | 7 +++++++ .markdownlint.yml | 7 +++++++ .npmrc | 1 + README.md | 5 ++--- package.json | 10 ++++++++++ 7 files changed, 55 insertions(+), 3 deletions(-) create mode 100644 .editorconfig create mode 100644 .github/workflows/lint.yml create mode 100644 .gitignore create mode 100644 .markdownlint.yml create mode 100644 .npmrc create mode 100644 package.json diff --git a/.editorconfig b/.editorconfig new file mode 100644 index 0000000..d2466d8 --- /dev/null +++ b/.editorconfig @@ -0,0 +1,13 @@ +# EditorConfig helps developers define and maintain consistent +# coding styles between different editors and IDEs +# editorconfig.org + +root = true + +[*] +end_of_line = lf +charset = utf-8 +trim_trailing_whitespace = true +insert_final_newline = true +indent_style = space +indent_size = 2 diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml new file mode 100644 index 0000000..395b69a --- /dev/null +++ b/.github/workflows/lint.yml @@ -0,0 +1,15 @@ +name: 'Lint Markdown' + +on: [pull_request, push] + +permissions: + contents: read + +jobs: + lint: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v3 + - uses: ljharb/actions/node/install@main + name: 'nvm install lts/* && npm install' + - run: npm run lint diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..601d8f2 --- /dev/null +++ b/.gitignore @@ -0,0 +1,7 @@ +# gitignore + +node_modules + +npm-shrinkwrap.json +package-lock.json +yarn.lock diff --git a/.markdownlint.yml b/.markdownlint.yml new file mode 100644 index 0000000..edf4f2f --- /dev/null +++ b/.markdownlint.yml @@ -0,0 +1,7 @@ +# for reference, see https://github.com/DavidAnson/markdownlint/blob/main/schema/.markdownlint.yaml + +# Default state for all rules +default: true + +# MD013/line-length - Line length +MD013: false diff --git a/.npmrc b/.npmrc new file mode 100644 index 0000000..43c97e7 --- /dev/null +++ b/.npmrc @@ -0,0 +1 @@ +package-lock=false diff --git a/README.md b/README.md index b0fb2b7..21d2f77 100644 --- a/README.md +++ b/README.md @@ -36,7 +36,7 @@ The `team` consists of engineers from across groups within IBM and Red Hat who: - The Web Application Reference focusses on the front-end, the existing [Node.js Reference Architecture](https://github.com/nodeshift/nodejs-reference-architecture) is the corresponding reference with a focus on the back-end. - + ## Outline 1. Design @@ -48,11 +48,10 @@ The `team` consists of engineers from across groups within IBM and Red Hat who: 1. Internationalization 1. Observability 1. Accessibility -1. Performance +1. Performance ## Contributing To Contribute to this project, please see the [Contributing Guide](./CONTRIBUTING.md). ## Contributors - diff --git a/package.json b/package.json new file mode 100644 index 0000000..fbd30ec --- /dev/null +++ b/package.json @@ -0,0 +1,10 @@ +{ + "private": true, + "scripts": { + "lint": "markdownlint-cli2 '**/*.md' '!node_modules'", + "lint:fix": "markdownlint-cli2-fix '**/*.md' '!node_modules'" + }, + "devDependencies": { + "markdownlint-cli2": "^0.7.1" + } +} From b1da5c617eb428a209597d48983ec6e0327ad501 Mon Sep 17 00:00:00 2001 From: David Sint Date: Sat, 22 Jul 2023 19:04:00 +0100 Subject: [PATCH 5/8] Include comments from 19 Jul Meeting - Include new section on relevant sections from Node.js Reference Architecture and include links to that asset in that section - Edit the header section to include IBM/RedHat value-add i.e. how IBM/RedHat have found benefit in using the headers and how we go about using them and setting the policy - Add commentry from the team on threat modeling to enhance this section into its own titled topic including mentions to tools like Threat Dragon and the STRIDE method of threat analysis - Include cookies as its own headed topic - Add OAuth as a note, though this is something @roastlechon may want to add to --- README.md | 3 ++- docs/security/security.md | 42 ++++++++++++++++++++++++++------------- 2 files changed, 30 insertions(+), 15 deletions(-) diff --git a/README.md b/README.md index 21d2f77..3fb4229 100644 --- a/README.md +++ b/README.md @@ -33,7 +33,7 @@ The `team` consists of engineers from across groups within IBM and Red Hat who: - Whenever possible components should have been validated at scale within the `team's` JavaScript/Node.js deployments or in engagements with our customers. - We need to consider licensing and other due diligence when mentioning components. -- The Web Application Reference focusses on the front-end, the existing [Node.js Reference +- The Web Application Reference focuses on the front-end, the existing [Node.js Reference Architecture](https://github.com/nodeshift/nodejs-reference-architecture) is the corresponding reference with a focus on the back-end. @@ -55,3 +55,4 @@ The `team` consists of engineers from across groups within IBM and Red Hat who: To Contribute to this project, please see the [Contributing Guide](./CONTRIBUTING.md). ## Contributors +- David Sint - Senior Technical Consultant - IBM diff --git a/docs/security/security.md b/docs/security/security.md index 971f443..10f4428 100644 --- a/docs/security/security.md +++ b/docs/security/security.md @@ -3,18 +3,29 @@ ## Overview Security is strongest from conscious design at the outset, rather than retroactively filling gaps after a solution has been built. In this respect, security should be considered at every stage of the application's lifecycle. IBM & RedHat call this practice [Security and Privacy by Design (SPbD)](https://www.redbooks.ibm.com/abstracts/redp4641.html) and recommend it for all systems, including web applications. -A [threat model](https://www.ibm.com/garage/method/practices/code/threat-modeling/) should be considered based on the attack surface that the Web Application creates. A public-facing web application for highly confidential personal data will have a very different threat model to an internal web application that doesn't contain sensitive data nor control anything of value. - -This section focuses on some of the common security threats to defend against and mitigation techniques to utilise from the `team`'s experience building web applications. +This section focuses on the experiences the `team` have had when building web applications to defend against and mitigate security threats. --- +## Relevant Resources From [Node.js Reference Architecture](https://github.com/nodeshift/nodejs-reference-architecture) +1. [Secure Development Process](https://github.com/nodeshift/nodejs-reference-architecture/blob/main/docs/development/secure-development-process.md#secure-development-process) +2. [Cross Origin Communication](https://github.com/nodeshift/nodejs-reference-architecture/blob/main/docs/development/cross-origin.md) + ## Guidance +Since security should feature in all components of the application life-cycle, the `team` have found it helpful to start with understanding an application's security landscape in a 'threat model'. This informs the practitioner with a prioritised list of threats as well as mitigations and methods of validation. The rest of this section includes examples of threats, mitigations, and tools that the `team` have found useful to consider. + +### Threat Modeling +A [threat model](https://www.ibm.com/garage/method/practices/code/threat-modeling/) should be considered based on the attack surface that the Web Application creates. A public-facing web application for highly confidential personal data of high-target public figures may have a very different threat model to an internal web application that doesn't contain sensitive data nor control anything of significant value. -The consensus of the most critical security risks is codified by the Open Worldwide Application Security Project (OWASP) in the [OWASP Top Ten](https://owasp.org/www-project-top-ten/). This is the starting point for the `team` when considering attack vectors in a web application's threat model. +Depending on the resources available, a threat model can be as informal as simple conversations, to as detailed as a 'threat model workbook'. The workbook is a collection of documentats, diagrams and processes that evolves with the application over time to form an up-to-date threat model. In general, the higher the value of the application and its data, the greater the emphasis should be on having a more detailed threat model. -### Coding best security practices -- Do we need to copy [this](https://github.com/nodeshift/nodejs-reference-architecture/blob/main/docs/development/secure-development-process.md#managing-access-and-content-of-public-and-private-data-stores) [content](https://github.com/nodeshift/nodejs-reference-architecture/blob/main/docs/development/secure-development-process.md#writing-defensive-code) +When considering what can go wrong, the consensus of the most critical security risks is codified by the Open Worldwide Application Security Project (OWASP) in the [OWASP Top Ten](https://owasp.org/www-project-top-ten/). This is called a threat list, and is often the starting point for the `team` when considering attack vectors in a web application's threat model. However, the OWASP Top Ten is just one example of a threat list and indeed threat lists is just one method of threat detection. Each application should will differ and therefore other threat detection methods like the [STRIDE](https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats#stride-model) categorisation model are also useful to consider. + +Further Threat modeling resources: +1. [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) +2. [OWASP Threat Dragon](https://owasp.org/www-project-threat-dragon/) + +### Coding Best Security Practices - Moving secrets to backend - secrets should not be exposed to the client-side - Bot detection - e.g. CAPTCHA @@ -34,6 +45,9 @@ Broken access control was the top security risk in the 2021 OWASP top ten. The t - Cookies (including HTTP only) - Token handling and storage e.g. JWTs - Protecting routes on client-side routing (SPAs) +- @roastlechon can talk about IBM's experience rolling custom auth before moving to KeyCloak and then to OAuth & OIDC + +### Securing Cookies ### Cross Site Attacks @@ -45,15 +59,15 @@ Broken access control was the top security risk in the 2021 OWASP top ten. The t ### Security Headers -The following are response headers that the `team` use to protect web applications. They should be configured with policies according to the web app's usage and threat model. +The following are response headers that the `team` use to protect web applications. They should be configured with policies according to the web app's usage and threat model. I general heuristic the `team` use is to keep the policies as restrictive as possible, and only to reduce the restrictions if functionally necessary. -- `Content-Security-Policy` to declare a policy for trusted application sources from which the browser can load resources such as scripts, stylesheets, images, fonts, etc. -- `X-Frame-Options` to declare whether the web app can be placed into an iframe on another domain -- `Strict-Transport-Security` to declare that the website requires HTTPS for encrypted subsequent requests -- `Referrer-Policy` to control what, if any information is included in the `Referer` header for network requests -- `X-Content-Type-Options` to prevent MIME sniffing attacks and force the declared content type instead of allowing a browser to interpret it, leaving room for malicious manipulation +- `Content-Security-Policy` to declare a policy for trusted application sources from which the browser can load resources such as scripts, stylesheets, images, fonts, etc. The `team` start with a restrictive policy like `default-src 'self'`, and allow-list other sources if needed. +- `X-Frame-Options` to declare whether the web app can be placed into an iframe on another domain. The `team` start with setting this to `DENY`, and only ease the restriction if required. +- `Strict-Transport-Security` to declare that the website requires HTTPS for encrypted subsequent requests. The `team` sets this to `max-age=63072000; includeSubDomains; preload` as recommended by [Chromium](https://hstspreload.org/), though this can be altered if required e.g. due to network or subdomain incompatibility with HTTPS. +- `Referrer-Policy` to control what, if any information is included in the `Referer` header for network requests. This can also be set as a `meta` tag in the `head` of an HTML document, or within an anchor tag, however the `team` try to find the most scalable method e.g. including the policy as a header set by the web application framework. This policy can be more granular if required, like if some links require the `Referer` header for analytics or affiliate programmes. +- `X-Content-Type-Options` to prevent MIME sniffing attacks and force the declared content type instead of allowing a browser to interpret it, leaving room for malicious manipulation. The `team` sets this to `nosniff`. -### Secure deployment +### Secure Deployment - Do we need to copy https://github.com/nodeshift/nodejs-reference-architecture/blob/main/docs/development/secure-development-process.md#maintaining-a-secure-and-up-to-date-foundation-for-deployed-applications? @@ -63,7 +77,7 @@ The following are response headers that the `team` use to protect web applicatio - Preventing Supply Chain attacks - Vulnerability audits -### Security testing & monitoring +### Security Testing & Monitoring - Pen testing - Fuzzing From 45e81bf18e040198fe7130d00cde9a16f8f343b8 Mon Sep 17 00:00:00 2001 From: David Sint Date: Sun, 23 Jul 2023 07:40:26 +0100 Subject: [PATCH 6/8] fix: linting --- README.md | 1 + docs/security/security.md | 16 +++++++++++----- 2 files changed, 12 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 3fb4229..4b16ee5 100644 --- a/README.md +++ b/README.md @@ -55,4 +55,5 @@ The `team` consists of engineers from across groups within IBM and Red Hat who: To Contribute to this project, please see the [Contributing Guide](./CONTRIBUTING.md). ## Contributors + - David Sint - Senior Technical Consultant - IBM diff --git a/docs/security/security.md b/docs/security/security.md index 10f4428..31e999c 100644 --- a/docs/security/security.md +++ b/docs/security/security.md @@ -1,6 +1,7 @@ # Security ## Overview + Security is strongest from conscious design at the outset, rather than retroactively filling gaps after a solution has been built. In this respect, security should be considered at every stage of the application's lifecycle. IBM & RedHat call this practice [Security and Privacy by Design (SPbD)](https://www.redbooks.ibm.com/abstracts/redp4641.html) and recommend it for all systems, including web applications. This section focuses on the experiences the `team` have had when building web applications to defend against and mitigate security threats. @@ -8,24 +9,29 @@ This section focuses on the experiences the `team` have had when building web ap --- ## Relevant Resources From [Node.js Reference Architecture](https://github.com/nodeshift/nodejs-reference-architecture) + 1. [Secure Development Process](https://github.com/nodeshift/nodejs-reference-architecture/blob/main/docs/development/secure-development-process.md#secure-development-process) -2. [Cross Origin Communication](https://github.com/nodeshift/nodejs-reference-architecture/blob/main/docs/development/cross-origin.md) +1. [Cross Origin Communication](https://github.com/nodeshift/nodejs-reference-architecture/blob/main/docs/development/cross-origin.md) ## Guidance + Since security should feature in all components of the application life-cycle, the `team` have found it helpful to start with understanding an application's security landscape in a 'threat model'. This informs the practitioner with a prioritised list of threats as well as mitigations and methods of validation. The rest of this section includes examples of threats, mitigations, and tools that the `team` have found useful to consider. ### Threat Modeling + A [threat model](https://www.ibm.com/garage/method/practices/code/threat-modeling/) should be considered based on the attack surface that the Web Application creates. A public-facing web application for highly confidential personal data of high-target public figures may have a very different threat model to an internal web application that doesn't contain sensitive data nor control anything of significant value. Depending on the resources available, a threat model can be as informal as simple conversations, to as detailed as a 'threat model workbook'. The workbook is a collection of documentats, diagrams and processes that evolves with the application over time to form an up-to-date threat model. In general, the higher the value of the application and its data, the greater the emphasis should be on having a more detailed threat model. When considering what can go wrong, the consensus of the most critical security risks is codified by the Open Worldwide Application Security Project (OWASP) in the [OWASP Top Ten](https://owasp.org/www-project-top-ten/). This is called a threat list, and is often the starting point for the `team` when considering attack vectors in a web application's threat model. However, the OWASP Top Ten is just one example of a threat list and indeed threat lists is just one method of threat detection. Each application should will differ and therefore other threat detection methods like the [STRIDE](https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats#stride-model) categorisation model are also useful to consider. -Further Threat modeling resources: +Further threat modeling resources: + 1. [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) -2. [OWASP Threat Dragon](https://owasp.org/www-project-threat-dragon/) +1. [OWASP Threat Dragon](https://owasp.org/www-project-threat-dragon/) ### Coding Best Security Practices + - Moving secrets to backend - secrets should not be exposed to the client-side - Bot detection - e.g. CAPTCHA @@ -69,7 +75,7 @@ The following are response headers that the `team` use to protect web applicatio ### Secure Deployment -- Do we need to copy https://github.com/nodeshift/nodejs-reference-architecture/blob/main/docs/development/secure-development-process.md#maintaining-a-secure-and-up-to-date-foundation-for-deployed-applications? +Secure deployment has been introduced in the Node.js Reference Architecure section on [secure development processes](https://github.com/nodeshift/nodejs-reference-architecture/blob/main/docs/development/secure-development-process.md#maintaining-a-secure-and-up-to-date-foundation-for-deployed-applications) ### Dependency Management @@ -82,4 +88,4 @@ The following are response headers that the `team` use to protect web applicatio - Pen testing - Fuzzing - SAST/DAST -- Active monitoring & incident response +- Active monitoring & incident response From cbfad27c514aa7cddd3a67556e03e2e79a4e0761 Mon Sep 17 00:00:00 2001 From: David Sint Date: Sun, 23 Jul 2023 08:33:46 +0100 Subject: [PATCH 7/8] Topics on Secret Security & Bot detection This commit takes the bullet points on keeping secrets secure, and bot detection and fleshes them out with content, guidance and tools that have been used by the team. --- docs/security/security.md | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/docs/security/security.md b/docs/security/security.md index 31e999c..3cb0b55 100644 --- a/docs/security/security.md +++ b/docs/security/security.md @@ -32,8 +32,20 @@ Further threat modeling resources: ### Coding Best Security Practices -- Moving secrets to backend - secrets should not be exposed to the client-side -- Bot detection - e.g. CAPTCHA +#### Keeping Secrets Secure + +Web applications often need access to protected systems like databases, and third-party services. These systems usually use credentials like passwords and API keys for access management. These credentials should be kept secret and should not be exposed to unauthorised users or they will be able to steal and use the credentials to access the data or services. Since client-side code is exposed to users, even if the route is protected from some users, these credentials should not be sent to the client e.g. in client JavaScript. + +Instead, these secrets should be securely stored on a server, which should carry out necessary functionality on behalf of the client for example by fetching data from a database before writing it to the DOM, or returning the data in a specialised format like JSON or XML to the client. Since the user has no visibility to the internals of the server, the credentials can be kept out of reach from end-users. + +#### Bot Detection & Prevention + +If a web page contains user-submittable content, content that should not be easily copied, or content that uses a large amount of server compute, then we recommend considering applying a form of bot protection to prevent spam, web scraping, or unnecessarily expending compute. You should first consider if bots are intended to be able to access the web page's content, for example search engine crawlers. Pages like login or registration pages may be highly targeted, for example in credential stuffing attacks which look to try to see if previously leaked email and password combinations have been reused on other applications. For pages or actions that should be protected from bots, these are some of the mitigating tools to limit or prevent this kind of activity that the `team` have used: + +1. CAPTCHA services like [hCaptcha](https://www.hcaptcha.com/) or [reCAPTCHA](https://www.google.com/recaptcha/about/) +1. Edge Bot Management Services like [Akamai Bot Manager](https://www.akamai.com/products/bot-manager) or [Cloudflare Bot Management](https://www.cloudflare.com/products/bot-management/) + +Rate limiting ### Encrypted Data & Traffic From c48bfdfdc6c4a452bca21b3b321fb8191fb3e3cc Mon Sep 17 00:00:00 2001 From: David Sint <44842045+DavidSint@users.noreply.github.com> Date: Sun, 23 Jul 2023 14:22:43 +0100 Subject: [PATCH 8/8] Add guidance on helmet library --- docs/security/security.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/security/security.md b/docs/security/security.md index 3cb0b55..225ec57 100644 --- a/docs/security/security.md +++ b/docs/security/security.md @@ -85,6 +85,8 @@ The following are response headers that the `team` use to protect web applicatio - `Referrer-Policy` to control what, if any information is included in the `Referer` header for network requests. This can also be set as a `meta` tag in the `head` of an HTML document, or within an anchor tag, however the `team` try to find the most scalable method e.g. including the policy as a header set by the web application framework. This policy can be more granular if required, like if some links require the `Referer` header for analytics or affiliate programmes. - `X-Content-Type-Options` to prevent MIME sniffing attacks and force the declared content type instead of allowing a browser to interpret it, leaving room for malicious manipulation. The `team` sets this to `nosniff`. +When using a framework like Express, the `team` have benefited from using the [helmet.js](https://helmetjs.github.io/) library to add these headers to web applications. + ### Secure Deployment Secure deployment has been introduced in the Node.js Reference Architecure section on [secure development processes](https://github.com/nodeshift/nodejs-reference-architecture/blob/main/docs/development/secure-development-process.md#maintaining-a-secure-and-up-to-date-foundation-for-deployed-applications)