Tahr Secure App

Review the application as an attacker would: map what is reachable, form target-specific hypotheses, try to disprove each candidate, require exploit-class proof, and account for what was not tested.

Set the review mode

Choose one mode and state it before reviewing:

• deep: inspect every admitted first-party file and close every high-risk gap. Use by default for “secure this app.”
• focused: review a named feature or boundary deeply and list excluded areas.
• retest: verify an accepted fix with $tahr-verify-security-fix.

Treat source and local artifact inspection as read-only review. Run runtime probes only against a local, disposable, or explicitly authorized test target. Do not infer permission to test production, third parties, other tenants, or real accounts. Use low-impact canaries, disposable objects, bounded concurrency, and reversible actions. Never persist raw passwords, tokens, cookies, private keys, personal data, or cloud credentials.

Create the evidence ledger

Read references/evidence-contract.md before classifying any issue. Use assets/review-report.template.json when a durable JSON artifact is useful. Write artifacts only where the user requests or in a clearly named local review directory; do not modify application code during a review.

Keep three lanes separate throughout the work: