Report a vulnerability

Email admin@softwaresecurity.com. Please include:

  • the affected page address, download file name or lab;
  • what an attacker could do, and what they need to do it;
  • the steps to reproduce it, with a minimal proof of concept that uses synthetic data;
  • your browser and operating system and their versions, or for a download the Node.js, Python or other runtime you ran it with;
  • whether the issue is already public or reported elsewhere;
  • how you would like to be credited, or that you prefer not to be.

Do not send passwords, production tokens, private keys or personal data. There is no encrypted reporting channel yet: if your evidence is sensitive, send a summary first and we will agree how to transfer the rest. Reports in English are preferred.

Scope

In scope:

  • The website at softwaresecurity.com: its pages and the code that runs in your browser, including search, the SBOM checker, the theme and progress storage, and the security headers and Content Security Policy the site sets.
  • The downloads under softwaresecurity.com/downloads/: project, lab and fix card archives, templates and guide exports. A download is vulnerable if it does something its README does not describe or harms the computer it runs on, for example by listening beyond localhost or writing outside its own folder, or if a reference solution, or a fix a guide recommends, still has the weakness it claims to fix.
  • The browser labs: code entered in a lab escaping the sandbox to reach the page, the network or stored data, or a lab that passes a repair that is still vulnerable.

Out of scope:

  • The deliberate vulnerabilities in starter code, exercise files and the vulnerable examples in guides: they are what the lesson teaches you to fix.
  • The hosting platform, its infrastructure and its sign-in pages; the domain registrar and DNS provider; and the third-party websites the guides link to. Report those to their owners.
  • Vulnerabilities in third-party software the site uses, such as Astro, Pagefind or QuickJS: report them upstream, and tell us as well if this site is affected.
  • Denial of service, load testing, social engineering, phishing and physical attacks.
  • Findings without a demonstrated security impact, such as scanner output without a reproduction, version numbers, or self-XSS that requires pasting code into your own browser’s developer tools. Hardening suggestions are welcome at the same address and are handled as improvements.
  • Errors in a guide that are not a security weakness in a fix it recommends: send those to admin@softwaresecurity.com as corrections.

Safe harbor

If you make a good-faith effort to follow this policy while researching the systems in scope, we consider your research authorized, we will not pursue or support legal action against you for it, and if anyone else takes action against you over research that followed this policy, we will make it known that it was authorized. This authorization covers only systems we control: it cannot authorize testing of the hosting platform or any other third party.

While you research:

  • test in your own browser and on your own copies of the downloads; the site has no user accounts, so do not try to reach other visitors’ browsers or data;
  • keep automated requests to the site below 10 per second, and stop if the site slows down;
  • use synthetic data, and if you come across someone else’s personal data, stop, do not keep or share it, and tell us;
  • give us the time set out below to fix the issue before you publish it.

What to expect

  • We acknowledge your report within 3 business days.
  • Within 7 days of receiving it we tell you whether we can reproduce it, how severe we consider it and what happens next. If we disagree with your assessment, we explain why.
  • We update you at least every 14 days until the issue is resolved.
  • We aim to fix a confirmed vulnerability, or remove what is affected, within 7 days if it is critical, 30 days if high, 60 days if medium and 90 days if low.

Critical means script running in other visitors’ browsers on this site, a download that has been altered, or code escaping the lab sandbox. High means a download or recommended fix that harms the computer it runs on or is still exploitable for the weakness it addresses, or a way past the Content Security Policy. Medium and low cover issues with a narrower impact or that need unlikely conditions.

Disclosure and credit

Please wait until we have published a fix, or 90 days after your report, whichever comes first, before you publish details. If a fix needs longer, we will explain why and agree a new date with you. If an issue is being exploited, we may publish a fix and a notice sooner, and we will tell you before we do.

With your permission, we credit you in the acknowledgments below by the name or handle you choose, with a link if you want one; otherwise your report stays anonymous. This policy offers no payment or bug bounty.

Acknowledgments

Fixed vulnerabilities and the people who reported them are listed here, with the reporter’s permission. No reports have been credited yet.

Machine-readable contact information (security.txt) points here.