Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolve #1941 by requiring HSTS preload for L3 apps #1996

Merged
merged 1 commit into from
Jul 24, 2024
Merged

Resolve #1941 by requiring HSTS preload for L3 apps #1996

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions 5.0/en/0x50-V50-Web-Frontend-Security.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,7 @@ The category focuses on requirements that protect against attacks that are execu
| **50.2.5** | [MODIFIED, MOVED FROM 14.4.7] Verify that the content of a web application cannot be embedded in a third-party site by default and that embedding of the exact resources is only allowed where necessary by using suitable Content-Security-Policy: frame-ancestors. Note that the X-Frame-Options solution is obsoleted. | ✓ | ✓ | ✓ | 1021 |
| **50.2.6** | [ADDED, SPLIT FROM 14.5.3] Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allow list of trusted origins. When "Access-Control-Allow-Origin: *" needs to be used, verify that the responses do not include any sensitive information. | ✓ | ✓ | ✓ | 183 |
| **50.2.7** | [ADDED] Verify that the Content-Security-Policy header specifies a location to report violations. | | | ✓ | |
| **50.2.7** | [ADDED] Verify that the application's top-level domain (e.g. site.tld) is added to the public HSTS preload list so that the use of TLS for the application will be built directly into the main browsers rather than only relying on the relevant HTTP response header | | | ✓ | |

## V50.3 Browser Origin Separation

Expand Down Expand Up @@ -78,3 +79,4 @@ For more information, see also:
* [Sandboxing third-party components](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html#sandboxing-content)
* [OWASP Secure Headers Project](https://owasp.org/www-project-secure-headers/)
* [OWASP Cross-Site Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)
* [HSTS Browser Preload List submission form](https://hstspreload.org/)
1 change: 0 additions & 1 deletion 5.0/en/0x99-Appendix-X_Recommendations.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,6 @@ The following items are in-scope for ASVS. We don't think they should be made ma
* Create a publicly available security.txt file at the root or .well-known directory of the application that clearly defines a link or e-mail address for people to contact owners about security issues.
* Client-side input validation should be enforced in addition to validation at a trusted service layer as this provides a good opportunity to discover when someone has bypassed client-side controls in an attempt to attack the application.
* Prevent accidentally accessible and sensitive pages from appearing in search engines using a robots.txt file, the X-Robots-Tag response header or a robots html meta tag.
* Use the HSTS preload list so that the use of TLS for the application will be built into the main browsers rather than only relying on the relevant HTTP response header.

## Software Security processes

Expand Down
Loading