New CSP Requirement

[jmanico]

I suggest we have a CSP requirement that moves folks away from allow-lists to a nonce or hash strict-dynamic policy (CSP3 stuff) which is much easier to deploy and more secure.

[elarlang]

Another CSP related discussion: https://github.com/OWASP/ASVS/issues/1297

[tghosth]

@jmanico are you able to draft the suggested text?

[Sjord]

I would also recommend CSP3 with nonces, but I would not require it. For some applications a CSP with allow-lists works fine and provides adequate security. I would not require these applications to move to CSP with nonces.

[tghosth]

Seemed to be support for CSP staying as Level 1 in #1297 so I closed that but I think we still need to decide how we want it to read in 5.0. Currently it looks like this:

14.4.3

[MODIFIED] Verify that a Content Security Policy (CSP) response header is in place that helps mitigate impact for XSS attacks like HTML, DOM, CSS, JSON, and JavaScript injection vulnerabilities.

@jmanico or @Sjord could you make any sensible or more prescriptive modifications here?

[elarlang]

Problem 1: Content-Security-Policy also is defense against ClickJacking or User Interface Redress in general. At the moment it's covered with separate requirement (14.4.7), but hopefully soon we can get rid of X-Frame-Options part as IE is almost not used already.

Problem 2: maybe we should set the focus of the wording from "mitigating XSS" to "loading and communicating only with allow-listed resources". Or we can ask "fetch, document, navigation and reporting directives are all set" / for loading and communicating only allow-listed resources / for mitigating XSS attacks

[tghosth]

Ok, to me Content Security policy is a well known enough control that we don't need to see what it protects against but rather be more prescriptive about how it should be considered which is what I am looking for suggestions for :)

We could also split into multiple requirements for L1, L2 and L3

[tw2as]

I totally agree with @Sjord comment: here.

IMO the end solution should be minimum set of CSP rules that should be applied at each level eg. not allowing script-src=unsafe-inline from L2 etc.

In order not to make it too verbose it can be based on CSP tools (like Google CSP Evaluator or CSP Auditor - Burp Suite Extension) and not allow for High severity finding from L2 and Medium severity finding from L3

[elarlang]

If we want say in details what CSP should do, we need entire paragraph of requirements for that.

Using nonces are better and more flexible, but at the same time - I would not say we should block using allow-list method, it does not provide less security. Also, the context - from "XSS" perspective, this requirement is a 2nd layer of defense.

What the requirement should say is that the header must be present for every rendered HTTP responses, including error messages from the webserver.

[tghosth]

I also agree with @tw2as here and @Sjord here but I also agree that the requirement cannot be too long.

Can someone come up with a proposed wording or split for the levels?

This should be also considered in #1230

[jmanico]

I am ok to drop this and not get over CSP perscriptive

[tghosth]

to be honest, I would like it to be slightly more prescriptive but I don't want to have to define the text myself :)

[elarlang]

Do we talk about new CSP Requirement like the issue title says or we talk about updating current requirement?

With current requirement I would use my previous proposal as input: Or we can ask "fetch, document, navigation and reporting directives are all set" / for loading and communicating only allow-listed resources / for mitigating XSS attacks.

[jmanico]

allow-lists are not at all recommended for CSP policies. Nonce based policies are way more secure.

https://research.google/pubs/pub45542/ https://www.researchgate.net/publication/313452289_Adopting_Strict_Content_Security_Policy_for_XSS_Protection

[tw2as]

I would recommend the following:

For the CSP section description:

Any new web project should have a CSP implemented at the beginning of the project and initially be set very strictly. Then during the implementation it might be loosen up depending on the specific needs and accepted risks in the project.

For legacy applications CSP implementation should start with using Content-Security-Policy-Report-Only with report-uri (over https) in order to report CSP violations.

The initial CSP can start with:

default-src 'self';
script-src 'self' 'unsafe-inline';
style-src 'self' 'unsafe-inline';
img-src 'self' data:;
font-src 'self';
form-action 'self';
frame-ancestors 'self';
base-uri 'self';
object-src 'self'; 

Please note:

• 'unsafe-inline' should be removed if possible
• any of 'self' should be replaced with 'none' if possible

It's highly recommended to use CSP validator (like csp-evaluator.withgoogle.com) to verify the strength of the CSP rules.

The actual ASVS requirements:

From Level 1: CSP should be implemented without 'unsafe-eval', should be checked with CSP validators and be as strict as possible.

From Level 2: CSP should be implemented without 'unsafe-inline' in script-src

From Level 3: CSP should be checked with CSP validators and have no Red / High severity findings. Every finding should be and addressed and secured in some other way.

[tghosth]

I really like this idea @tw2as.

For your L1 control, is "should be checked with CSP validators and be as strict as possible." practical/testable?

[elarlang]

For me it's wrong direction. This requirements does not describe any rules other than "it should exist".

What is "valid" validator? What is "as strict as possible"? The requirement does not describe, what must be achieved.

In "initial CSP" - why not object-src with none, base-uri with none etc? My point is, we can not say any starter CSP as every application is different.

Basically we just need to sent the message, at via browser, (in HTML or JavaScript; injection or execution situation - it should not be possible to do any communication for loading resources or send requests which are not valid based on application needs.

[tw2as]

@elarlang - I get your point that initial CSP wouldn't work for some projects. How about the following CSP section description?

Any new web project should have a CSP implemented at the beginning of the project and initially be set very strictly by disabling every CSP directive by setting it's value to 'none'. Then during the implementation it might be loosen up depending on the specific needs and accepted risks in the project.

For legacy applications CSP implementation should start with using Content-Security-Policy-Report-Only with report-uri (over https) in order to report CSP violations.

It's highly recommended to use CSP validator (like csp-evaluator.withgoogle.com) to verify the strength of the CSP rules.

@tghosth - I get your porint that some of those requirements are not testable. If we can to base the requirements on external CSP validator (which I believe is updated more often then the ASVS itself) then I would base it on https://csp-evaluator.withgoogle.com.

Ideally I would prefer to force no high severity findings from L2 and no medium severity findings from L3 but I guess for some projects (especially legacy) it could be to difficult to achieve therefore I propose the following:

From Level 1: Verify that a Content Security Policy (CSP) response header is in place which helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities and that it does not have 'unsafe-eval' value. From Level 2: Verify that a Content Security Policy (CSP) response header does not have 'unsafe-inline' value in 'script-src' directive. From Level 3: Verify Content Security Policy (CSP) response header value with CSP validator (https://csp-evaluator.withgoogle.com/) to make sure that it does not have any High severity findings.

[jmanico]

Strongly disagree to suggest whitelist policies like this. Nonce & strict-dynamic policies are much much stronger.--Jim @. Coding Education+1 (808) 652-3805On Jan 5, 2023, at 12:56 PM, Tomasz Wrobel @.> wrote: @elarlang - I get your point that initial CSP wouldn't work for some projects. How about the following CSP section description?

Any new web project should have a CSP implemented at the beginning of the project and initially be set very strictly by disabling every CSP directive by setting it's value to 'none'. Then during the implementation it might be loosen up depending on the specific needs and accepted risks in the project. For legacy applications CSP implementation should start with using Content-Security-Policy-Report-Only with report-uri (over https) in order to report CSP violations. It's highly recommended to use CSP validator (like csp-evaluator.withgoogle.com) to verify the strength of the CSP rules.

@tghosth - I get your porint that some of those requirements are not testable. If we can to base the requirements on external CSP validator (which I believe is updated more often then the ASVS itself) then I would base it on https://csp-evaluator.withgoogle.com. Ideally I would prefer to force no high severity findings from L2 and no medium severity findings from L3 but I guess for some projects (especially legacy) it could be to difficult to achieve therefore I propose the following:

From Level 1: Verify that a Content Security Policy (CSP) response header is in place which helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities and that it does not have 'unsafe-eval' value. From Level 2: Verify that a Content Security Policy (CSP) response header does not have 'unsafe-inline' value in 'script-src' directive. From Level 3: Verify Content Security Policy (CSP) response header value with CSP validator (https://csp-evaluator.withgoogle.com/) to make sure that it does not have any High severity findings.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[tghosth]

@elarlang I think that @tw2as is on the right track as long as the suggestions are testable/verifable.

@tw2as Jim's original request was to focus around a "nonce or hash strict-dynamic" type policy but it looks like that is not specified by your requirements, are you able to clarify that in your suggested text?

[elarlang]

From @jmanico

Strongly disagree to suggest whitelist policies like this. Nonce & strict-dynamic policies are much much stronger.

Jim, fight mode on and not reading? :)

Where exactly in my comment (https://github.com/OWASP/ASVS/issues/1311#issuecomment-1372370316) I say anything about whitelist?

Basically we just need to send the message, at via browser, (in HTML or JavaScript; injection or execution situation - it should not be possible to do any communication for loading resources or send requests which are not valid based on application needs.

In fact, I don't. It's achievable using allow-lists, it's achievable using nonces. And like we have discussed here before - nonce and strict-dynamic is not something we can force to be used over allow-list approach. Application is not more vulnerable when it uses allow-listed sources correctly.

With nonces I think you may have problems when you try to cache static content, as nonce itself is not static and cacheable.

I still stand for my previously linked comment and we should not say anything about script-src in CSP, because this is "hidden client-side architecture requirement in CSP"

If we want to force script-src or unsafe-eval or whatever similar to (not) being used, we should declare them as separate requirements and CSP is just "block the functionality if it's not done correctly or an attack (attempt) happened".

From @tw2as

For the CSP section description:

Any new web project should have a CSP implemented at the beginning of the project and initially be set very strictly. Then during the implementation it might be loosen up depending on the specific needs and accepted risks in the project.

For legacy applications CSP implementation should start with using Content-Security-Policy-Report-Only with report-uri (over https) in order to report CSP violations.

I agree with all the content, but I'm not sure, it's a content for the ASVS. Feels more like Cheat Sheet content for me.

From Level 3: Verify Content Security Policy (CSP) response header value with CSP validator (https://csp-evaluator.withgoogle.com/) to make sure that it does not have any High severity findings.

I don't like dependency on external tools, as we don't know what those will do in the future. In a way it's against ASVS versioning - let's say application A was valid against CSP rule on date X, then it was retested again on date Y and it was not valid anymore. In ASVS it could be breaking change. If someone has idea to link requirement text to some tool, then we actually need to point clearly, what we need to achieve (with this tool and without mentioning this tool).

[tw2as]

@tghosth - it's testable as it requires verification of the CSP response header. @jmanico - it's a good point to include Nonce although it's important that it's generated every time and it's generated with crypto secure generator.

I understand the point that we don't want to include external tools (I guess it more suitable for Cheat Sheet). I propose the following:

• From Level 1: Verify that a Content Security Policy (CSP) response header is in place which helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities and it does not contain 'unsafe-eval' value.
• From Level 2: Verify that a Content Security Policy (CSP) response header does not contain 'unsafe-inline' value in 'script-src' directive or if it contains 'unsafe-inline' it also must contain a 'nonce' value (which makes 'unsafe-inline' only work with older browsers for compatibility)
• From Level 2: If Content Security Policy (CSP) response header contains a 'nonce' value, verify that it was generated on every load with a cryptographically secure pseudo-random number generator (CSPRNG).

I am not sure if forcing strict-dynamic over allow-list is nesesery. @jmanico if you think so that it's a case of adding the following:

• Verify that a Content Security Policy (CSP) response header contains 'strict-dynamic' value if it loads scripts from external domains.

[jmanico]

Application is not more vulnerable when it uses allow-listed sources correctly.

94% of whitelist policies are bypassable. They are much less secure. I can point out the research if it helps. It is much more difficult to build a secure CSP allow-list policy than it is to build a nonce based one.

[jmanico]

@jmanico - it's a good point to include Nonce although it's important that it's generated every time and it's generated with crypto secure generator.

Agreed. If you need that level of scale also consider csp hashing based policies which even work with CDN's and are static policies unlike nonces!

[tw2as]

I agree that loading scripts with nonce is more secure then allow list but I am not sure if ASVS should force it and force 'strict-dynamic'. Maybe it should be recommended in the cheat series instead.

[jmanico]

I do agree it's a slippery slope trying to make suggestions for CSP requirements....

[tw2as]

Yes it is, but I still believe that together we can come up with some general minimum CSP requirements in ASVS

[elarlang]

I feel that we are on loop here already, but I try to explain it once more.

We can say in CSP only, that browser should not load any other resource etc than application needs.

If we are going to disallow <script>javascript here</script> tag from HTML via CSP, it's an hidden requirement and forces to change building HTML and JavaScript part differently (not using any inline script tags). I don't say it's wrong thing to ask, I say, it's wrong place to ask it. Especially when it's forced via external tool and in ASVS requirement you don't have basically any hint on this.

Another things with CSP - rules are usually per application, but requirements are really different per page or URL. If we want to address something, then with level 3 we can keep this in mind. It's done that way for requirement 14.4.7.

[tghosth]

@elarlang based on what you are saying in https://github.com/OWASP/ASVS/issues/1311#issuecomment-1377853036, do you have a suggestion of how you would reword the suggestion from @tw2as: https://github.com/OWASP/ASVS/issues/1311#issuecomment-1375350144

[elarlang]

Note that the current CSP requirement is moved to 50.2.1.

[tghosth]

I would suggest we raise the current L1 requirement to be L2 and move towards something more prescriptive for L3 such as:

Verify that a strict nonce or hash based Content Security Policy (CSP) response header is in place to provide increased simplicity and security.

We should then make sure we have a link to the CSP cheat sheet.

https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html

If no one has objections, I will open a PR next

[elarlang]

If no one has objections, I will open a PR next

I have, mostly listed here: https://github.com/OWASP/ASVS/issues/1311#issuecomment-1374939469

[tghosth]

Ok but I have still been less prescriptive in what I proposed here, do you still object to a strict CSP at L3?

[tghosth]

Ok, I think that being too prescriptive here is a problem. But we also need to specify a goal for the CSP other than just adding a header.

The current text is:

[MODIFIED, MOVED FROM 14.4.3] Verify that a Content Security Policy (CSP) response header is in place that helps mitigate impact for XSS attacks like HTML, DOM, CSS, JSON, and JavaScript injection vulnerabilities.

This is a relevant statement from @elarlang above:

Basically we just need to sent the message, at via browser, (in HTML or JavaScript; injection or execution situation - it should not be possible to do any communication for loading resources or send requests which are not valid based on application needs.

We need to set out the goals for the CSP and maybe have separate requirements for the different aspects which CSP can help with.

Default disallow should be in place

[tghosth]

Just keeping this thread up to date with our latest thinking, I think we need a CSP requirement, (even PCI 4.0 has that now). I think we need to keep the implementation side relatively abstract and refer to external resources but we need to be clear about the goals of the CSP.

[elarlang]

Based on my comments https://github.com/OWASP/ASVS/issues/1311#issuecomment-1369842654 and https://github.com/OWASP/ASVS/issues/1311#issuecomment-1372370316, it should be something like:

Verify that the Content-Security-Policy header defines fetch, document, and navigation directives based on application needs, without allowing the browser to communicate any other resource and deny everything by default.

Note, that "the Content-Security-Policy" header is not correct as multiple Content-Security-Policy are allowed.

edit: discussion on the proposal is moved to issue https://github.com/OWASP/ASVS/issues/1958

[tw2as]

Verify that the Content-Security-Policy header defines fetch, document, and navigation directives based on application needs, without allowing the browser to communicate any other resource and deny everything by default.

IMO it should be more technical in terms of the actual CSP configuration to at least encourage using: default-src: none and discouraged using: unsafe-line. How about something like this:

Verify that the Content-Security-Policy header defines fetch, document, and navigation directives based on application needs, without allowing the browser to communicate any other resource and deny everything by default with the directive default-src: none. To reduce the risk of malicious scripts, it is strongly advised against including the 'unsafe-inline' value in the script-src directive. Instead, consider using external files for all scripts or implementing nonce-hashes for inline scripts.

[elarlang]

I have addressed my view on hidden requirements, for example here: https://github.com/OWASP/ASVS/issues/1311#issuecomment-1374939469

I still stand for my previously linked comment and we should not say anything about script-src in CSP, because this is "hidden client-side architecture requirement in CSP"

... and here https://github.com/OWASP/ASVS/issues/1311#issuecomment-1377853036

If we are going to disallow tag from HTML via CSP, it's an hidden requirement and forces to change building HTML and JavaScript part differently (not using any inline script tags). I don't say it's wrong thing to ask, I say, it's wrong place to ask it. Especially when it's forced via external tool and in ASVS requirement you don't have basically any hint on this.

Whatever is "strongly advised" is not a requirement and should not belong to a requirement. It's a recommendation and can be presented as such - we have a separate recommendation paragraph now.

edit: discussion on the proposal is moved to issue https://github.com/OWASP/ASVS/issues/1958

[elarlang]

I tried to conduct recommendation for that, but ended up with a monster. But hopefully usable for a starter and discussion:

To be able to get benefits from the Content-Security-Policy header fetch directive for script and style for disallowing using inline tags and eval for an attacker, the application should not use inline tags for script and style and should not allow 'unsafe-inline' and 'unsafe-eval' for script and style.

And then we should create another recommendation for using nonces instead of allow-lists.

edit: discussion on the proposal is moved to issue https://github.com/OWASP/ASVS/issues/1958

[Sjord]

Indeed, we should recommend to avoid unsafe-inline, but not require it.

implementing nonce-hashes for inline scripts

I think nonces and hashes are separate things, and both are acceptable to secure inline scripts.

the application should not use inline tags for script and style

Inline scripts and styles can be secured using nonces or hashes, so completely advising against inline scripts is not needed in my opinion.

[elarlang]

I think nonces and hashes are separate things, and both are acceptable to secure inline scripts.

In case you meant SRI with "hashes" part, I agree, but hashes and nonces are addressing different attack vectors - we have SRI covered in other requirement:

V50.6.1 [MODIFIED, MOVED FROM 14.2.3] Verify that if client-side assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset.

[elarlang]

Inline scripts and styles can be secured using nonces or hashes, so completely advising against inline scripts is not needed in my opinion.

Well, I confused myself here :) To save time for @Sjord to explain, I'll do it myself.

At first, I thought you meant SRI, but I rechecked the part and verified (for myself), that the integrity parameter is usable, only when the browser is going to fetch external resources.

Proof-of-concept: https://h2ck3r.eu/sri.html - integrity is made for alert(1), but alert(2) is also executed.

The same is said here: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity#using_subresource_integrity

At the same time, I'm not sure it should be that way, and found one interesting related issue to be open: https://github.com/w3c/webappsec-subresource-integrity/issues/44

What @Sjord probably meant, was using hashes for the Content-Security-Policy, and for illustration, I made proof-of-concept for this as well: https://h2ck3r.eu/csp-hash/

For serving the response, HTTP response header is set:

Content-Security-Policy: script-src 'sha256-GHqmE7my6OF2QBoGTnGw0BKjE4T56LeeVuMeNPRvLWU='

HTML document itself:

<html>
<script>alert(3);</script>
<script>alert(4);</script>
</html>

Only alert(3) is executed, because alert(4) is not allowed by script-src as the hash is not listed there.

edit: discussion on the proposal is moved to issue https://github.com/OWASP/ASVS/issues/1958

[elarlang]

My first proposal (https://github.com/OWASP/ASVS/issues/1311#issuecomment-2107564410) addressed only communication with external parties, but it does not cover the document integrity part, which is addressed by the unsafe-inline topic.

Instead of saying "Do not use 'unsafe-inline'" we should try to explain the goal of the restriction.

In case there is an HTML injection vulnerability, disallowing using inline scripts should make the attacker's life more interesting.

In case there is a JavaScript injection in an inline script (between <script> .. </script> tags in an HTML document), an attacker can do a successful attack without communicating with any external party. Note, that also the nonce for the <script> tag does not help in this case.

If to go for the requirement direction (instead of recommendation), it should carry ideas:

Verify that

• the application does not use inline scripts and styles in HTML documents and has not allowed using those in the Content-Security-Policy header
• OR all inline styles and scripts integrity are covered by checksum hashes in the Content-Security-Policy header

.. now, how to make it twice shorter :)

Feels like a level 3 requirement.

For the chapter, maybe this requirement should be together with "SRI" requirement and the current "V50.6 External Resource Integrity" to be renamed to "V50.6 Resource Integrity".

ping @Sjord @tw2as @tghosth - your ideas?

edit: discussion on the proposal is moved to issue https://github.com/OWASP/ASVS/issues/1958

[jmanico]

I suggest that mentioning the use of nonces or hashing with strict-dynamic (also know as “strict CSP”) is exactly what we should be suggesting.

Here is a AI hit that describes strict-CSP. Suggest at least some of these for a level 3 CSP requirement. Lots of studies from Google showing how effective this is.

Caution AI content, you may be triggered

A Strict Content Security Policy (CSP) is a security measure used to prevent various types of attacks, such as Cross-Site Scripting (XSS), data injection, and other code execution attacks, by controlling the resources a web page is allowed to load. CSP is implemented using the Content-Security-Policy HTTP header.

Key Features of a Strict CSP

1. No Inline Scripts or Styles: Inline JavaScript and CSS are prohibited. This means no script tags with JavaScript code, and no style tags with CSS, nor style attributes on elements. All scripts and styles must be loaded from external sources.

2. No eval() or Similar Functions: The use of eval() and other functions that execute strings as code (like setTimeout() with string arguments) are not allowed. This prevents dynamically constructed scripts from running.

3. Default-Src Directive: A strict CSP uses the default-src directive to specify a whitelist of trusted sources from which content can be loaded. This can include specific domains or self (the same origin).

4. Script-Src and Style-Src Directives: These directives further restrict the sources for scripts and styles. For instance, script-src 'self' means only scripts from the same origin are allowed.

5. No Wildcards: Avoiding the use of wildcards (*) ensures that only explicitly specified sources are trusted. This prevents unexpected sources from loading content.

6. Nonces or Hashes: To allow inline scripts or styles when absolutely necessary, strict CSP can use nonces or hashes. Nonces are randomly generated tokens that are added to scripts or styles and matched in the CSP header. Hashes are cryptographic digests of the script or style content.

Example of a Strict CSP Header

Here’s an example of a strict CSP header:

Content-Security-Policy: 
  default-src 'none'; 
  script-src 'self' 'sha256-abc123...'; 
  style-src 'self' 'sha256-def456...'; 
  img-src 'self'; 
  connect-src 'self'; 
  font-src 'self'; 
  object-src 'none'; 
  frame-ancestors 'none'; 
  base-uri 'self'; 
  form-action 'self'

• default-src 'none': Disallow loading content from any source by default.
• script-src 'self' 'sha256-abc123...': Allow scripts only from the same origin or those that match the specified hash.
• style-src 'self' 'sha256-def456...': Allow styles only from the same origin or those that match the specified hash.
• img-src 'self': Allow images only from the same origin.
• connect-src 'self': Allow connections (e.g., AJAX requests) only to the same origin.
• font-src 'self': Allow fonts only from the same origin.
• object-src 'none': Disallow loading objects such as Flash or other plugins.
• frame-ancestors 'none': Disallow the page from being framed.
• base-uri 'self': Restrict the base URI to the same origin.
• form-action 'self': Allow forms to be submitted only to the same origin.

Benefits

• Mitigates XSS Attacks: By disallowing inline scripts and use of eval(), CSP greatly reduces the risk of XSS attacks.
• Limits Data Injection: Restricting sources helps prevent the injection of malicious resources.
• Improves Code Integrity: Using nonces and hashes ensures that only intended scripts and styles are executed.

Challenges

• Compatibility: Some legacy applications might rely heavily on inline scripts and styles, making it challenging to implement CSP without significant refactoring.
• Maintenance: Keeping CSP rules updated as the application evolves can be demanding, especially with dynamic content.
• Debugging: Initial implementation might require debugging due to blocked resources, which can be time-consuming.

Implementation Tips

1. Start with Reporting: Use Content-Security-Policy-Report-Only to test policies without enforcing them. This allows you to identify and fix issues without breaking the application.

2. Gradual Adoption: Implement CSP incrementally, starting with non-critical parts of the application to identify and resolve compatibility issues.

3. Use Tools: Utilize tools like CSP evaluators and browser extensions to help formulate and test policies.

4. Regular Audits: Continuously monitor and audit your CSP to ensure it remains effective as the application evolves.

A strict CSP is a powerful defense mechanism, but it requires careful planning and implementation to avoid disrupting legitimate functionality while maximizing security benefits.

[elarlang]

Yes, Jim, it triggers - instead of analyzing what was generated and what is expected in the issue context, you just throw miles of generated text into me/us to analyze. Or you are not able to analyze and validate it yourself? What is the value of this?

Content wise - please make difference what and why we require and what we recommend. Those are different things. For me, the allow-list vs nonces are something to recommend, but not to have an requirement. This point of view is shared also by others (e.g Sjord), but it all expects, you actually read the issue first...

[jmanico]

Elar, if you have nothing positive to say then I suggest you do not say anything.

[jmanico]

Please note, there is a lot of solid science and study showing the Strict-CSP is by far the most effective. It's a lot more detailed and nuanced that what the discussion has provided, this is why I dropped the full text for those who wish to dig deeper.

[elarlang]

I'm pretty sure, all who contributing here, know those things anyway. What we need here is help with recommendations, wordings, dividing different directives to different topics and risk-levels. Not just noise.

Elar, if you have nothing positive to say then I suggest you do not say anything.

I described the need here and repeated time-wasting problems from issue to issue. If one listens, I don't need to repeat them.

[jmanico]

I disagree Elar. I think your comments are downright abusive and it needs to stop. All comments are welcome here. If you do not like what I am saying then please stop reading my comments and stop making negative comments. We need adults here and respectful communication even when you disagree. All technical comments should be acceptable from the community, including my own.

[jmanico]

PS @elarlang I am the one who started this thread suggesting strict-CSP policies. And now I clearly defined what that is. It's a good thing.

[elarlang]

I disagree Elar. I think your comments are downright abusive and it needs to stop.

This is not true, and it is pure demagogy. In another issue, you said that I didn't understand the topic, the same in the email, but at the end, you were the one, who did not read the issue (again) and failed to understand the topic. The summary is here: https://github.com/OWASP/ASVS/issues/1589#issuecomment-2103948623

Here, yes, you started the issue. The discussion here has been developing to the place, where it is.

From issue to issue you throw in comments, without reading and analyzing, what has been said before, causing noise in the issue, and then no one wants to dig through all the comments that are there.

If you think after all that behavior, that I'm the one who needs to change, then the result is quite simple - one of us will not continue as leader for ASVS.