Despite being a simple, beneficial, and standardized way for security researchers to report vulnerabilities, adoption of security.txt files (as defined by RFC 9116) remains disappointingly low. A 2025 study by Hartwork found that the vast majority of IT companies, including many prominent names, still do not provide a security.txt file on their websites. This lack of adoption hinders responsible vulnerability disclosure and potentially leaves these organizations more susceptible to exploitation, as researchers lack clear reporting channels. The study emphasizes the continued need for greater awareness and adoption of this straightforward security best practice.
CSRF and CORS address distinct web security risks and therefore both are necessary. CSRF (Cross-Site Request Forgery) protects against malicious sites tricking a user's browser into making unintended requests to a trusted site where the user is already authenticated. This is achieved through tokens that verify the request originated from the trusted site itself. CORS (Cross-Origin Resource Sharing), on the other hand, dictates which external sites are permitted to access resources from a particular server, focusing on protecting the server itself from unauthorized access by scripts running on other origins. While they both deal with cross-site interactions, CSRF prevents malicious exploitation of a user's existing session, while CORS restricts access to the server's resources in the first place.
Hacker News users discussed the nuances of CSRF and CORS, pointing out that while they both address security concerns related to cross-origin requests, they protect against different threats. Several commenters emphasized that CORS primarily protects the server from unauthorized access by other origins, controlled by the server itself. CSRF, on the other hand, protects users from malicious sites exploiting their existing authenticated sessions on another site, controlled by the user's browser. One commenter offered a clear analogy: CORS is like a bouncer at a club deciding who can enter, while CSRF protection is like checking someone's ID to make sure they're not using a stolen membership card. The discussion also touched upon the practical differences in implementation, like preflight requests in CORS and the use of tokens in CSRF prevention. Some comments questioned the clarity of the original blog post's title, suggesting it might confuse the two distinct mechanisms.
The Okta bcrypt incident highlights crucial API design flaws that allowed attackers to bypass account lockout mechanisms. By accepting hashed passwords directly, Okta's API inadvertently circumvented its own security measures. This emphasizes the danger of exposing low-level cryptographic primitives in APIs, as it creates attack vectors that developers might not anticipate. The post advocates for abstracting away such complexities, forcing users to interact with higher-level authentication flows that enforce intended security policies, like lockout mechanisms and rate limiting. This abstraction simplifies security reasoning and reduces the potential for bypasses by ensuring all authentication attempts are subject to consistent security controls, regardless of how the password is presented.
Several commenters on Hacker News praised the original post for its clear explanation of the Okta bcrypt incident and the proposed solutions. Some highlighted the importance of designing APIs that enforce correct usage and prevent accidental misuse, particularly with security-sensitive operations like password hashing. The discussion touched on the tradeoffs between API simplicity and robustness, with some arguing for more opinionated APIs that guide developers towards best practices. Others shared similar experiences with poorly designed APIs leading to security vulnerabilities. A few commenters also questioned Okta's specific implementation choices and debated the merits of different hashing algorithms. Overall, the comments reflected a general agreement with the author's points about the need for more thoughtful API design to prevent similar incidents in the future.
Summary of Comments ( 1 )
https://news.ycombinator.com/item?id=43235972
Hacker News users generally agreed with the premise that security.txt adoption is disappointingly low, with several expressing frustration at the security industry's failure to implement basic best practices. Some commenters pointed out that even security-focused companies often lack a security.txt file, highlighting a general apathy or ignorance towards the standard. Others discussed the potential downsides of security.txt, such as increased exposure to automated vulnerability scanning and the possibility of it becoming a target for social engineering attacks. A few suggested that the lack of adoption might stem from the perceived lack of clear benefits or fear of legal repercussions for disclosed vulnerabilities. The overall sentiment reflects a concern for the slow uptake of a seemingly simple yet beneficial security measure.
The Hacker News post titled "Most IT companies fail to serve security.txt for RFC 9116 in 2025" generated a moderate number of comments discussing the adoption (or lack thereof) of the security.txt standard. Several commenters expressed a general sentiment of disappointment and frustration with the slow uptake of such a simple, yet beneficial, security practice.
One compelling line of discussion revolved around the practical challenges and perceived lack of incentives for companies to implement security.txt. Some argued that security researchers often find vulnerabilities through means other than those advertised in a security.txt file, therefore diminishing its perceived value for companies. Others countered this point by highlighting the importance of providing a clear and official channel for reporting vulnerabilities, regardless of how they are discovered. This, they argued, can help streamline the vulnerability disclosure process and prevent researchers from resorting to less secure or less desirable methods of contact.
Another commenter pointed out that the absence of security.txt often leads to wasted time and effort for security researchers who have to resort to searching for contact information through various channels, potentially leading to delayed vulnerability disclosures. This reinforces the argument that security.txt benefits both the reporting party and the receiving organization.
The issue of discoverability also arose, with some commenters questioning how effective security.txt is if search engines aren't indexing it reliably. This raised concerns about the practical utility of the standard if it's not easily findable by those who need it.
Finally, a few comments touched upon the potential legal implications of not having a security.txt file, suggesting that in the future, its absence might be considered negligent, especially in regulated industries. This adds another layer of incentive for companies to adopt the standard, moving beyond best practice and towards a potential legal requirement.
While no single comment was overwhelmingly compelling in isolation, the collective discussion painted a picture of a security standard struggling with adoption despite its simplicity and potential benefits. The comments highlighted the tension between the perceived effort required for implementation and the potential benefits, as well as the need for improved discoverability and potential future legal implications that might drive wider adoption.