docs: say how to report a vulnerability privately - #91
Merged
Conversation
A public repository with accounts, a database and a live API had no disclosure policy. GitHub's Security tab showed nothing, so a finder's realistic options were a public issue or silence — and a public issue for an auth bypass is the worst outcome for everyone. Written against what this app actually exposes rather than from a template. It has a server, accounts, user data and a signing key in Key Vault, so the threat model is the ordinary one for an authenticated API: bypassing authentication, missing authorisation on a data-bearing path, token handling, and anything crossing a trust boundary. The seeded demo account is named as deliberately not a vulnerability. It exists so the app can be tried without registering, and someone would otherwise reasonably report being able to log into it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A public repository with accounts, a database and a live API had no disclosure policy. GitHub's Security tab showed nothing, so a finder's realistic options were a public issue or silence — and a public issue for an auth bypass is the worst outcome for everyone.
Written against what this app actually exposes, not from a template:
There is a server, accounts, user data, and a signing key in Key Vault. So the threat model is the ordinary one for an authenticated API — and the document says so rather than implying there is nothing to find.
Highlighted as worth reporting: authentication or authorisation bypass (reading another user's todos is the highest-value finding), token handling and revocation, the Google sign-in path, rate-limit bypass on auth, injection, XSS, and user enumeration by timing — login deliberately hashes a dummy password for unknown users so both cost the same.
Named as not vulnerabilities
The seeded demo account (
demo@todoapp.local) is called out explicitly. It exists so the app can be tried without registering; without saying so, someone would reasonably report being able to log into it.Also: "the API is public" (it is meant to be — what matters is what an unauthenticated caller can do), and CVE reports with no path to exploitation, since NuGet audit already fails the build on any advisory with a fix.
ClaudeChessApp and LotteryApp already had one. Net10Sudoku's follows separately — its surface is different enough (a Blazor server, but no accounts and no data) that copying this one would have been wrong.