The card below is the “product under test”. Use guided mode to see the bug list upfront, or blind mode to find them yourself first.
Techniques: Security testing, Error guessing
Account recovery
After submitting, you’ll see a confirmation. Check the URL for your reset token.
Recent activity
[2026-04-18 09:14] Login OK - user: admin@resync.nz - ip: 192.168.1.1
[2026-04-18 09:22] Login FAILED - user: admin@resync.nz - pass: Winter2024! - ip: 203.0.113.42
[2026-04-18 09:31] Password reset - token: a1b2c3d4e5f6 - user: guest@example.com
[2026-04-18 09:22] Login FAILED - user: admin@resync.nz - pass: Winter2024! - ip: 203.0.113.42
[2026-04-18 09:31] Password reset - token: a1b2c3d4e5f6 - user: guest@example.com
Your findings
0 / 0 bugs foundTick each bug as you confirm it on the page above. Progress saves automatically.
Write down every bug you find. Be specific — where it is, what’s wrong, what it should be.
Planted bugs (6)
- Reset tokens in URLs are logged in browser history, server access logs, and referrer headers. Tokens should be sent via email body only, never in URLs.
- The activity log shows:
pass: Winter2024!— logging passwords (even failed ones) is a critical security vulnerability. Passwords must never be logged. - The log entry shows the raw reset token
a1b2c3d4e5f6. Tokens in logs can be harvested to hijack account recovery flows. - Showing internal network IPs in a user-facing activity log exposes internal infrastructure topology.
- The email input uses
type="text"— no format validation. A minor issue compared to the log vulnerabilities, but still a bug. - The form has no CAPTCHA, no rate limit indicator, and no lockout after repeated attempts — signals that brute-force protection may be absent.
Security surface: look for sensitive data in logs, tokens in URLs, missing input type validation, and absence of rate limiting signals. The log entry with a plaintext password is a Critical finding.