Skip to content

docs: say how to report a vulnerability privately - #91

Merged
bgard68 merged 1 commit into
mainfrom
docs/security-policy
Aug 2, 2026
Merged

docs: say how to report a vulnerability privately#91
bgard68 merged 1 commit into
mainfrom
docs/security-policy

Conversation

@bgard68

@bgard68 bgard68 commented Aug 2, 2026

Copy link
Copy Markdown
Owner

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.

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.
@bgard68
bgard68 merged commit be5ccd7 into main Aug 2, 2026
3 checks passed
@bgard68
bgard68 deleted the docs/security-policy branch August 2, 2026 17:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant