Public-safe method kit and AI-OS for responsible bug hunting, evidence review, redaction, and report preparation.
Plain-English definitions for common bug-hunting and reporting terms.
The exact places and actions you are allowed to test. If scope is unclear, stop.
A system, app, endpoint, domain, repository, or feature. An asset is testable only when it is in scope.
A route or API location that accepts requests, such as /api/notes/{noteId}.
Proof of identity, such as signing in.
Permission to access a specific object, action, tenant, role, or feature after identity is known.
The signed-in state for a user. Do not publish real session values.
A permission group, such as standard user, manager, or admin. Role bugs happen when a lower role can do a higher-role action.
A customer, workspace, organization, or account boundary inside a larger system.
A value that points to an object. In public notes, use placeholders like OBJECT_1, not real values.
The relationship between a user and an object, such as USER_A owning OBJECT_1.
Insecure Direct Object Reference. In plain English, a user can access another user’s object because ownership is not checked correctly.
Broken Object Level Authorization. This is a broader API term for object-level authorization failures, including many IDOR-style issues.
The rule that separates what one user, role, tenant, session, or object is allowed to do from what it is not allowed to do.
The expected baseline behavior. Example: USER_B can access OBJECT_2, which USER_B owns.
The one value changed during a controlled test. Example: changing OBJECT_2 to OBJECT_1 while keeping the user context the same.
Facts that prove what happened. Good evidence is minimal, reproducible, and safe to review.
Unprocessed captures, screenshots, request bodies, response bodies, or logs. Raw evidence often contains sensitive data and should not go in this public repo.
Evidence with private values replaced by placeholders such as USER_A, OBJECT_1, and {TOKEN_PLACEHOLDER}.
What unauthorized access, action, exposure, or privilege was actually proven.
Whether the behavior can be shown again under controlled, authorized conditions.
Whether a behavior has enough scope, proof, boundary crossing, and impact to be worth reporting.
A useful observation that does not prove a reportable vulnerability.
A finding that has already been reported or is already known to the program.
A suspected issue that turns out to be intended behavior, not reproducible, out of scope, or missing security impact.
Not allowed by the written testing rules. Do not test or submit it unless the program owner clarifies permission.
Personally identifiable information. Do not collect, store, or publish third-party PII.
A value used for access or identity. Do not publish real tokens.
A browser-stored value often used to keep a session active. Do not publish real cookies.
A control that limits how often an action can happen. Testing rate limits can be unsafe and is often forbidden.
A protection against misuse, such as spam, brute force, notification flooding, or payment abuse.
A message sent from one service to another when an event happens. Do not replay real webhooks unless explicitly authorized.
A record that something happened, such as EVENT_1 updating OBJECT_1.
The property that doing the same action twice should not create repeated side effects.
Stored data reused for speed. Cache bugs matter when one user or session receives another user’s data.
Old information still visible in the browser. Stale UI is usually weaker than fresh server-side access.
What the server actually allows or returns. This is usually stronger evidence than UI-only behavior.
What the browser or app interface shows. Client-side behavior alone may not prove impact if the server denies the action.
The process of deciding whether evidence proves a real, in-scope security issue.
A rule that tells you when to stop testing. Example: stop if third-party data appears or the next step would require guessing.
A review prompt that uses placeholders and summaries instead of secrets, raw evidence, or private data.
When an AI review makes the issue sound stronger than the evidence supports. Treat AI output as review help, not proof.
The process of reporting a security issue to the responsible owner through an approved channel.