Web Security Testing Checklist

Test, test, just keep testing ...

Sign up (Registration) Vulnerabilities#

This file lists account sign-up and verification problems found. Each item has: What, How to reproduce (simple steps), Impact, and Fix suggestion.

1. HTTP not HTTPS#

What: Site uses http:// instead of https://.
How to reproduce: Open site with http:// and check browser address bar.
Impact: Data (passwords, tokens) can be intercepted.
Fix suggestion: Redirect all http to https and enable HSTS.

2. No confirmation code required · can create account with admin email#

What: Registering does not require verifying email, so attacker can create account using admin@example.com.
How to reproduce: Register with admin@example.com and log in without email confirmation.
Impact: Attacker may control or claim accounts that belong to others.
Fix suggestion: Require email confirmation before activation or login.

3. Confirmation link can be used multiple times#

What: The email confirmation link works more than once.
How to reproduce: Click confirmation link, then click again · it still verifies or grants access.
Impact: Link reuse may allow attackers to re-verify or hijack flows.
Fix suggestion: Make token single-use and expire it after first use.

4. OTP rate limiting missing (if OTP is sent)#

What: One-time password (OTP) has no or weak rate limit.
How to reproduce: Request many OTPs for the same account and observe behaviour.
Impact: Attacker can brute-force or flood OTP system.
Fix suggestion: Limit OTP requests per IP and per account (e.g., 5 requests/hour).

5. OTP leaked in response (interceptable)#

What: OTP appears in server response or in a place that can be intercepted.
How to reproduce: Intercept registration or OTP request (e.g., with proxy) and check response for OTP value.
Impact: Attacker can read OTP and take over account.
Fix suggestion: Never include OTP in responses. Return only status messages; keep OTP server-side.

6. Pre-account takeover via enabling 2FA before confirming email#

What: Create an account, do not confirm email, then enable Two-Factor Authentication (2FA) from settings · this leads to pre-account takeover.
How to reproduce:

1. Create account with victim email but do not confirm.
2. Log in (if allowed) or go to settings.
3. Enable 2FA without email verification.
   Impact: Attacker can link 2FA to unverified account and later confirm or take over.
   Fix suggestion: Only allow security changes (2FA enable/disable) after email is confirmed.

7. Pre-account takeover via social link (Google/Facebook) before confirming#

What: Create account, do not confirm, then link social login (Google/Facebook) · this enables takeover.
How to reproduce:

1. Register with victim email (don’t confirm).
2. In settings, link Google/Facebook account.
3. Observe account becomes tied to attacker-controlled social identity.
   Impact: Attacker can later log in via social provider and access victim’s account.
   Fix suggestion: Allow social linking only after email verification or require owner confirmation.

8. Zero-auth scenario (0-auth) · attacker verifies victim via Google flow#

What: Attacker registers with victim@gmail.com and uses Google OAUTH flow so attacker account becomes verified without victim action.
How to reproduce (example flow):

1. Attacker creates account using victim@gmail.com.
2. Attacker completes Google OAUTH linking for that account (0-auth path).
3. The system marks the email as verified because Google returned a verified email.
   Impact: Verification bypass · attacker gets a verified account for someone else.
   Fix suggestion: When an email is already in use or unverified, require a confirmation link to be clicked in the email inbox before marking verified.

9. Verification bypass by changing email after linking#

What: Create account with victim@gmail.com, cannot verify, then change account email to hacker@gmail.com and the victim’s inbox shows verified. (Verification state is inconsistent.)
How to reproduce:

1. Create account with victim@gmail.com (unverified).
2. Try to verify · fail.
3. In settings, change account email to hacker@gmail.com.
4. Click the link in victim’s inbox (if present) and see victim@gmail.com becomes verified.
   Impact: Email verification logic broken · attacker can force verification or confuse ownership.
   Fix suggestion: Tie verification tokens to one email address and one account; changing email should invalidate previous tokens.

10. Delete account without password confirmation#

What: The site allows account deletion without asking for current password or re-authentication.
How to reproduce: Go to account delete page/setting and delete without entering password.
Impact: If attacker has brief access to a logged-in session, they can delete the account.
Fix suggestion: Require password entry or MFA confirmation to delete account.

11. XSS via username / name fields#

What: Username or name fields allow raw HTML/JS and cause Cross-Site Scripting (XSS). Example inputs include:

• "><u>anas

• "><svg/onload=confirm(document.cookie)>

• "><svg/onload=confirm(1)>

• "><img src="https://.../anonymous-gandhi.png"> How to reproduce: Set username to one of the examples, save, then visit profile or any page that shows the username. Look for script execution or HTML injection.
  Impact: Session theft, defacement, or malicious actions in victim browser.
  Fix suggestion: Properly escape or sanitize input before rendering. Use a whitelist for allowed characters in usernames. Encode output in HTML contexts.

• • -# Login Vulnerabilities (Simple English)

1. Login over HTTP, not HTTPS#

What: Login form uses http:// instead of https://.
Impact: Credentials can be intercepted during transfer.
Fix suggestion: Use HTTPS for all login pages and enforce HSTS.

2. No rate limit on password attempts#

What: Login page allows unlimited password attempts.
Reference: HackerOne report (opens in a new tab)
Impact: Enables brute-force attacks.
Fix suggestion: Implement rate limiting per IP/account and optional CAPTCHA after several failed attempts.

3. Default credentials allowed#

What: Site may allow default credentials like:

test:test, admin:admin, admin:password, kali:kali, admin:123
admin:default, root:root, root:toor, admin:kali, kali:root, admin:123456789

Impact: Attackers can gain immediate access.
Fix suggestion: Disable default credentials and enforce password change on first login.

4. SQL Injection in username#

What: Login form may be vulnerable to SQL injection.
Example payload: admin' or 1=1; --
Impact: Allows bypassing authentication or database access.
Fix suggestion: Use parameterized queries and input validation.

5. Response manipulation to bypass login#

What: Modify server response to bypass login page. go in burp suite --- login --- proxy ---do intercept ---change the response --- if we have

0 change to 1 false change to true failed change to successful

if we have 403 Forbidden change it to 200 OK

Notice You can do this automaticaly with Proxy settings --- match and replace rules ----- choice,match and replace dakchi li kayt3awd (false with true for exemple ) Impact: Could allow unauthorized access.
Fix suggestion: Implement proper server-side authentication checks.

6. Automated SQL Injection testing#

What: Capture login request and test with SQL injection tools (e.g., sqlmap -r req.txt).
Impact: Identifies SQL injection vulnerabilities.
Fix suggestion: Sanitize inputs and use parameterized queries.

7. XSS injection in username#

What: Inject XSS payloads in username field.
Example: <svg/onload=confirm()>
Impact: Executes JavaScript in user’s browser.
Fix suggestion: Sanitize and encode user input.

8. Template injection#

What: Inject template expressions in username.
Example: {{9*9}} · if output is 81, vulnerable.
Impact: Can execute server-side template code.
Fix suggestion: Escape template expressions and validate input.

9. Check for leaked credentials in page source#

What: Inspect page source with CTRL+U for hardcoded credentials.
Impact: Reveals sensitive data if present.
Fix suggestion: Never include credentials in client-side code or HTML.

Reset Password Vulnerabilities#

Methodology (general)#

1. Request a password reset email for an account.
2. Inspect the email link: check if it uses http:// or https://.
3. Copy the token or code from the email link.
4. Search for that token in Burp/Proxy history (requests & responses).
5. Replay or inspect the reset request to see if token appears in response, headers, or logs.
6. Test token reuse: use token once, then use it again.
7. Test token expiry: wait or change token timestamp and try to use it after expiry.
8. Try resetting many times quickly to check rate limiting (email bombing). Burp Intruder
9. Try resetting another account’s password using a known token or by changing parameters (ID/username).
10. Check if reset operation requires current password or re-authentication.
11. Test edge cases: long tokens, truncated tokens, altered tokens, or tokens in URL path vs body.
12. Ask reset password (from out) don't press on it ⇒ login to account ⇒ change the password = click on reset link if password changed through reset password link (bug)
13. Ask reset password (from out) don't press on it ⇒ login to account change the email and verify ⇒ click on reset link ⇒ if password changed through reset password link (bug)
14. Brute force OTP
15. For injection testing, capture a real reset request (req.txt) and run tools like sqlmap -r req.txt only on targets you are authorized to test.
16. Use an interactive OOB collaborator (e.g., Burp Collaborator) by using username@burp_collab.net as the reset email to detect server-side callbacks.

1. Reset link uses HTTP not HTTPS#

What: Reset link in email uses http:// instead of https://.
How to reproduce: Send reset email and open the link; observe http:// in email.
Impact: Token can be intercepted over the network (man-in-the-middle).
Fix suggestion: Use https:// for reset links and force HTTPS site-wide. Add HSTS.

2. Reset token leaked in request or response#

What: The reset token appears in server response or other requests (visible in Burp history).
How to reproduce: Copy token from email, search proxy history for token in request bodies, headers, or responses.
Impact: Attacker with access to logs or proxy can use token to reset password.
Fix suggestion: Never return tokens in responses. Only accept tokens server-side and avoid logging them. Mask tokens in logs.

3. Token is reusable (not single-use)#

What: The reset token can be used multiple times.
How to reproduce: Use token to reset password, then use same token again to reset again.
Impact: Token reuse increases window for takeover and replay attacks.
Fix suggestion: Make reset tokens single-use. Invalidate token immediately after successful reset.

4. Token does not expire or expiry too long#

What: Token either never expires or has a very long lifetime.
How to reproduce: Use token after long wait (or check token expiry time).
Impact: Stolen tokens remain valid for long time, increasing risk.
Fix suggestion: Use short expiry (e.g., 15-60 minutes) and store expiry server-side.

5. No rate limit on reset requests (Email bombing)#

What: Site allows many password reset requests for same account or many different accounts without throttle.
How to reproduce: Trigger many reset requests quickly and observe behaviour (emails sent).
Impact: Email bombing (annoyance, mail provider throttling), or helps brute-force flows.
Fix suggestion: Rate limit reset requests per IP and per account (e.g., 5/hr). Add CAPTCHAs for excessive requests.

6. Reset without re-authentication for sensitive changes#

What: After using reset link, site allows immediate sensitive actions (email change, add 2FA) without additional verification.
How to reproduce: Reset password, then change email or enable security features without extra confirmation.
Impact: If an attacker uses reset, they can fully take over account and lock owner out.
Fix suggestion: Require re-authentication for critical changes or require email re-confirmation for email changes.

7. Predictable or weak token generation#

What: Tokens are short, guessable, or follow a predictable pattern.
How to reproduce: Observe token formats and try to predict next tokens or brute-force small tokens.
Impact: Attacker can brute-force tokens and reset accounts.
Fix suggestion: Use cryptographically secure random tokens (sufficient length, e.g., 128-bit+), encoded safely.

8. Token in URL can leak via Referer header#

What: Token placed in full URL may be sent in Referer to third-party resources.
How to reproduce: Open reset link directing to page that loads third-party resources, check Referer in proxy.
Impact: Token may leak to external domains.
Fix suggestion: Put token in POST body, or use short landing page that reads token and immediately POSTs it without third-party requests. Use referrer-policy header.

9. IDOR: token works for different account if ID changes#

What: Reset request accepts token with different account identifier causing cross-account resets.
How to reproduce: Use token for victim but change account id/username parameter to target another account.
Impact: Attacker can reset other users’ passwords.
Fix suggestion: Bind token to a single account on server-side. Validate token → account mapping strictly.

10. No notification to user after password reset#

What: User is not notified (email or SMS) when password is changed.
How to reproduce: Reset password and check if any alert is sent to previous email.
Impact: Account owner may not notice takeover.
Fix suggestion: Send immediate notification to previous email or alternate contact when password changes.

15. Weak/new-password policy not enforced in reset flow#

What: The reset form allows weak passwords (short, common, or missing complexity).
How to reproduce: Use reset to set a weak password like 1234, password, or qwerty.
Impact: Accounts can be compromised easily by guessing or credential stuffing.
Fix suggestion: Enforce strong password policy during reset: minimum length (12+), complexity rules, check against breached-password lists. Provide password strength meter.

16. Token is GUID v1 (time-based) · sandwich / brute-forcing risk#

What: Token uses GUID v1 (time-based and possibly predictable) or otherwise encodes time/device info making it guessable or vulnerable to "sandwich" attacks (generating tokens around known timestamp).
How to reproduce: Inspect token format; if it matches GUID v1 pattern, attempt to generate nearby GUIDs and test.
Impact: An attacker who can predict or craft tokens may perform targeted resets or token collisions.
Fix suggestion: Use cryptographically random tokens (UUIDv4 or secure random bytes), do not encode predictable timestamps. Bind token to account and make single-use + short expiry.

Two-Factor Authentication (2FA) Security Checklist#

1. Default / weak 2FA code#

Check: Test common codes like 000000 or 123456.
Impact: Weak or default codes can allow bypass.
Fix suggestion: Reject common codes and enforce strong, random OTPs.

2. Null / empty 2FA#

Check: Submit empty or null OTP values.
Impact: May bypass 2FA if server accepts null values.
Fix suggestion: Always require valid, non-empty OTP input.

3. Reuse previous OTP#

Check: Submit a previously used OTP.
Impact: If accepted, OTPs are not properly invalidated.
Fix suggestion: Ensure OTPs are single-use only.

4. Use another account's OTP#

Check: Submit a valid OTP from a different account. the first (chrome) the second one (firefox) Impact: Allows cross-account compromise.
Fix suggestion: OTP must be linked to the specific user account.

5. No rate limit on 2FA attempts#

Check: Attempt multiple OTP submissions without restriction.
Impact: Brute-force attacks possible.
Fix suggestion: Limit attempts per session/IP and consider temporary lockouts.

6. OTP exposed code in server response#

Check: Inspect responses for OTP leaks.
Impact: Attackers may retrieve valid OTPs from server responses.
Fix suggestion: Never include OTPs in responses or logs.

7. Bypass via reset password or OAuth#

Check: Attempt to bypass 2FA using password reset link or 0-auth Google login. login ---- enable 2FA ---login with google --- if you got into directly then vulnerability or enable 2FA --- logout --- reset password --- then click on the link --- if you got into directly then vulnerability Impact: Can allow account takeover without 2FA.
Fix suggestion: Enforce 2FA on all authentication paths and sensitive actions.

8. No rate limit on sending 2FA codes#

Check: Trigger sending OTPs repeatedly.
Impact: Can spam users or be used for brute-force.
Fix suggestion: Implement rate limiting on OTP sending.

9. Response manipulation#

Check: Modify server response codes (e.g., 403 Forbidden → 200 OK).
Impact: May bypass 2FA verification.
Fix suggestion: Validate all 2FA steps server-side; never trust client-side codes.

10. Bypass via step logic#

Check: Manipulate the flow (false → 0 → true → 1, failed → successful).
or check the endpoints for exemple : we have 3 endpoints to login

/login /login2 /my-account?id=anas

Impact: Exploits logic flaws to bypass 2FA.
Fix suggestion: Properly validate all state transitions in 2FA workflow.

11. Enable 2FA without email verification#

Check: Enable 2FA without verifying account ownership.
Impact: Leads to pre-account takeover.
Fix suggestion: Verify ownership (email or phone) before enabling 2FA.

12. Enabling 2FA does not end other sessions#

Check: Activate 2FA and check if previous sessions remain active.
Impact: Attackers with existing sessions can retain access.
Fix suggestion: Invalidate all existing sessions upon 2FA activation.

Broken Session Management#

1. login to your account with firefox and chrome

change the password in firefox , observe the account in chrome is still logged in and didn't logout ---> Broken session Management

2. login to your account with firefox and chrome

enable 2FA in firefox reload the page in chrome and observe session is still valid

3. login to your account and update anything

intercept the request with burpsuite send the request to repeater logout from your account use the request in repater to update for exempe update user and if still valid khasso mayb9ach valid khass session tsali matb9ach salha wayy change drtih makhassoch ykhdl sinooooooooon vulnerability (vulnerability)

4. Ask for reset password

don't click on the link reached you

• login with your username and password
• change the password of the email
• logout from your account and then use the link in step 1

if still valid then (Vulnerability)

5. logout from your account

click on (Alt+Left-arrow) button or <-- observe the session and profile data is still found broken cache vulnerability

6. when updating email address

check if OTP is sent to existing email not the new email Broken function lead to verification bypass

7. create account with email A => victim

update the email to B => hacker then verify it -> vierfy your account - update email back to A => victim if shown as verified then vulnerability

8. verifiaction bypass

account with victim@gmail.com => don't verify it

• update account email to hacker@gmail.com once you clicked the link if verified victim@gmail.com then vul