OWASP
.well-known/security.txt adheres to RFC 9116
V1 Architecture, Design and Threat Modeling V11 Secure Software Development Lifecycle Requirement 1.1.8 states "[ADDED] Verify availability of 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.".
RFC 9116 was published during April 2022.
Section 3 of RFC 9116 mandates that at minimum, "... organizations MUST place the "security.txt" file under the "/.well-known/" path ...".
Therefore, I propose to change V1 Architecture, Design and Threat Modeling V11 Secure Software Development Lifecycle Requirement 1.1.8 to "[MODIFIED] Verify that .well-known/security.txt adheres to RFC 9116.".
From https://securitytxt.org/:
For websites, the security.txt file should be placed under the /.well-known/ path (/.well-known/security.txt) [RFC8615]. It can also be placed in the root directory (/security.txt) of a website, especially if the /.well-known/ directory cannot be used for technical reasons, or simply as a fallback. The file can be placed in both locations of a website at the same time.
I don't think it is super-important that security.txt adheres to the RFC, but it would be informative to reference the RFC in the requirement.
@Sjord
I don't think it is super-important that security.txt adheres to the RFC, but it would be informative to reference the RFC in the requirement.
Refer to https://github.com/OWASP/wstg/pull/946#issuecomment-1168764635
@Sjord
So what is the status of this issue? Can it be closed?
I need approval to submit the Pull Request as "1.1.8 [MODIFIED] Verify that .well-known/security.txt adheres to RFC 9116.".
First - for me personally the requirement is not that clearly in the scope - if we don't have the security.txt file, we don't have any extra vulnerability in the application. Yes, I understand, that in case someone finds some vulnerability and don't know how and to whom to report it, the report may not be sent and information not received.
Second - pointing to RFC. A lot of requirements are directly related to some RFC but we have not used this, because RFC's get some updates or they are obsoleted later and then "latest ASVS release" is pointing to obsoleted RFC. So the requirement text must send the intent of the requirement and in my opinion it is done with current version of 1.1.8.
@elarlang wrote:
First - for me personally the requirement is not that clearly in the scope - if we don't have the security.txt file, we don't have any extra vulnerability in the application. Yes, I understand, that in case someone finds some vulnerability and don't know how and to whom to report it, the report may not be sent and information not received.
This would put us at odds with MVSP "1.1 Vulnerability reports" and the OWASP Cheat Sheet if it is not captured in another OWASP Verification Standard.
@elarlang wrote:
Second - pointing to RFC. A lot of requirements are directly related to some RFC but we have not used this, because RFC's get some updates or they are obsoleted later and then "latest ASVS release" is pointing to obsoleted RFC. So the requirement text must send the intent of the requirement and in my opinion it is done with current version of 1.1.8.
Reword as "... RFC 9116 or later ..."
I think the requirement should be to have a clear contact address for security issues. Whether that is a security.txt or a contact form doesn't really matter to me.
This would put us at odds with MVSP "1.1 Vulnerability reports" and the OWASP Cheat Sheet if it is not captured in another OWASP Verification Standard.
Can you also point out, what exactly is written there "what would put us at odds"?
For me the requirement is out of ASVS scope.
I think we should keep it in scope although I accept that it is marginal.
We reference the security.txt website in a footnote so I have submitted a PR #1483 to make that clearer and refer to the RFC, I don't think we have to specifically mandate it in the requirement.
@tghosth - after getting more clear with the scope topic, do you want to keep this requirement?
If yes, then probably there is a need to find a new category for that. If not, then just remove it.
@elarlang wrote:
Can you also point out, what exactly is written there "what would put us at odds"?
The OWASP Vulnerability Disclosure Cheat Sheet states "A security.txt file on the website at /.well-known/security.txt as per RFC 9116" but is not reflected within ASVS.
@elarlang wrote:
For me the requirement is out of ASVS scope.
Therefore https://github.com/OWASP/ASVS/issues/1495#issuecomment-1818307147 would also remove security.txt from the scope of ASVS.
Another facepalm from @cmlh.
If the question was asked from @tghosth , the issue was assigned to @tghosth with the label "Awaiting response" - what makes you (@cmlh) think that you should answer and close this instead?
https://redmaple.tech/blogs/2022/survey-of-security-txt/ - some real world stats
This is something to recommend, not that much something to require. It gives for interested one point of contact, but for sure it gives for "another interested" one the same point of contact to phishing with scanning reports with no actual value.
If the application owner is not willing to have this communication flow and does not have security.txt in place, does not make the application more vulnerable. I consider it as part of the process.
hmm, good question. I think it falls in the scope of the application but the question is as you say whether the app is less secure without it, whether it is more a process control than a security requirement and whether we should mandate it or recommend it. I need to this about this one...
I made the PR.
Just documenting the removed requirement here:
| # | Description | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 1.1.8 | [ADDED] Verify availability of 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. | ✓ | ✓ | 1059 |
It makes sense to keep the issue opened till it's covered/solved for recommendation section/paragraph.