If you have found a security problem, thank you — please report it privately using the address below
rather than posting it publicly, and give it a reasonable chance to be fixed before disclosing it.
How to report
Email gaurav.gbaba@gmail.com. Include what you found, the steps to
reproduce it, and what an attacker could actually do with it. A proof of concept helps enormously.
Expect an acknowledgement within a few days. This is a personal project maintained by one person in their own time,
so fixes are best-effort and there is no bug bounty — that is said up front rather than after you have
spent your evening on it.
In scope
Authentication and session handling.
Anything that lets one account read or modify another account's data.
The demo (guest) sign-in path, which is the one endpoint that writes to the database without authentication.
Privilege escalation to an administrator role.
Out of scope
The study content being publicly readable. The notes and the practice bundle are served without
authentication deliberately — the demo mints a session in one click, so an authentication gate there would stop no
determined scraper while costing every genuine visitor a round trip. This is a decision, not an access-control bug.
Missing rate limits on read-only endpoints. Write paths are limited; reads are not, and that is accepted at this
scale.
Anything requiring physical or already-privileged access to the server.
Automated scanner output with no demonstrated impact.
Reports that amount to a missing hardening header with no exploitable consequence.
Safe harbour
Research conducted in good faith under this policy — without degrading the service for others, without accessing or
modifying data belonging to anyone else, and without publicly disclosing before a fix — is welcome, and no legal action
will be pursued over it. If in doubt about whether something crosses that line, ask first.