Login & Signup Testing Checklist.

Submit the signup form with all valid data. Assert the user is redirected to the expected destination (dashboard, email verification prompt, or onboarding flow) — NOT back to the signup page with a 200. Confirm the account exists by logging in immediately after.

Submit signup with an email that already has an account. The error message must NOT reveal whether the existing account is password-based or social-login-based (e.g., avoid 'This email is already linked to a Google account'). A safe message: 'An account with this email already exists.'

Rapidly double-click the submit button or submit the form via two concurrent API calls with the same email. The server must create exactly one account. The submit button should be disabled after the first click. Check the database state, not just the UI response.

Using the API directly (bypassing the UI), send a username of 1,000 characters or a bio of 50,000 characters. The server must return a 400 with a field-specific error. HTML maxlength alone is easily bypassed via DevTools or direct API calls.

Complete registration and assert the user lands on the authenticated destination without being shown the login page. Check that the session cookie or token is set correctly on the signup response, not only on a subsequent login call.

Inspect the DOM for every input/select in the signup form. Each must have an associated <label> via for/id pairing, or an aria-label/aria-labelledby attribute. Placeholder text disappears on focus and cannot serve as a label. Check with axe-core in CI.

Submit login with valid credentials and assert the response is a redirect (302/303) to the dashboard or intended destination. A 200 response on the login page URL itself means the redirect is missing and the user may appear logged out to client-side routing.

Test wrong password for a real email, and a nonexistent email. Both must return the identical error message and HTTP status. Distinguishing 'user not found' from 'wrong password' enables account enumeration.

After login, open DevTools → Application → Cookies and verify the session token cookie has: Secure (prevents HTTP transmission), HttpOnly (prevents JS access), and SameSite=Strict or Lax (CSRF mitigation). Missing HttpOnly allows XSS to steal the session.

Capture the session token before logout. Log out. Replay the captured token in a fresh API request to a protected endpoint. Expect 401, not 200. Client-side cookie deletion without server-side session invalidation leaves the session alive for token theft scenarios.

While logged out, navigate directly to /dashboard/settings. Assert a redirect to /login?returnTo=%2Fdashboard%2Fsettings. After logging in, assert the user lands on /dashboard/settings — not the generic dashboard root. Dropping the returnTo forces users to navigate manually every time.

Manually expire the session (delete the session cookie or fast-forward the token expiry in a test environment). Navigate to a protected page. Expect a clean redirect to login, not an unhandled 401 that renders a blank page or throws a TypeError in the console.

Clear all required fields and submit. Each required field must have a visible, adjacent error message — not only a generic banner at the top. Assert the form does NOT submit (no network request, or a 400 response with the expected error structure).

Reject: 'plainaddress', '@nodomain.com', 'user@'. Accept: 'user+tag@example.org', 'user@sub.domain.co.uk', 'first.last@corp.io'. Confirm errors reference the field specifically ('Please enter a valid email address') rather than a generic 'Invalid input'.

Using a tool like Postman or curl, POST to the registration endpoint with the same invalid data that the UI rejects. Expect a 400 with the same field-level error messages. Server-side validation must mirror client-side rules exactly.

Each error message element must have an id that matches the aria-describedby attribute of its corresponding input. Use a screen reader (VoiceOver or NVDA) or axe-core to verify the error message is associated and announced on focus or after submission.

Enter '<script>alert(document.cookie)</script>' into the username and display-name fields. Submit. Check both the registration success page (where the username may be displayed) and any error state. The string must appear as literal escaped text — not cause an alert or DOM mutation.

POST to the registration or change-password API with a 1-character password. Expect 400 with a clear error ('Password must be at least 8 characters'). The HTML minlength attribute is trivially bypassed — server enforcement is mandatory.

Register or change password with a 64-character and a 128-character passphrase. Both should succeed. Truncation at an undisclosed limit silently weakens passwords — a 64-char passphrase truncated to 20 chars is much weaker than the user intended.

Set a password like 'P@ssw0rd!🔐αβγ'. Register, log out, and log in with the identical string. If the login fails, the server is likely applying different encoding on registration vs. authentication, silently mutating the password.

Enter different values in the password and confirm-password fields. The error should appear before the request reaches the server (client-side check), and if the form is submitted via API directly with mismatched values, the server must also reject it with 400.

Inspect all API responses during registration and login (success and error). The submitted password must not appear in any response body, in any error message, or in any server log line (check log output if accessible). Logging passwords is a critical data breach risk.

Submit the password-reset form with a random email that has no account. The response must be identical to a valid email ('If an account exists, a reset email has been sent'). Differentiated responses allow attackers to enumerate registered emails.

Request a reset link, use it to set a new password, then attempt to use the same link again. The second use must return an error ('This link has already been used or has expired'). Reusable reset tokens are effectively persistent backdoors.

If the reset token has a 1-hour TTL, request a link, wait (or manipulate the token's expiry in a test environment), and attempt to use it after expiry. Expect a clear 'This link has expired. Please request a new one.' — not a 500 or a generic 'Invalid token'.

Log in on two browsers. Reset the password via browser A. Use browser B (which still has the old session) to access a protected route. Expect 401/redirect-to-login. Leaving old sessions alive after a reset undermines the security purpose of the reset.

Attempt to set a 1-character password via the reset form. The server must return a 400 with the password policy error — the same error shown during registration. Reset flows sometimes skip the password validation middleware.

Using a test OAuth provider account, complete the full social login flow. If the email matches an existing account, it should link to it (confirm with the user, or auto-link per your policy). If the email is new, it should create an account. Assert the user lands on the expected authenticated page.

At the provider's consent screen, click 'Deny' or 'Cancel'. Assert the app returns the user to /login (or the entry point) with a human-readable message ('Sign in with Google was cancelled'). A blank page, a 500, or an unhandled redirect is a UX failure.

Inspect the authorization URL generated for the OAuth flow. It must include a state parameter (random, per-request). The callback endpoint must validate the state against the value stored in the session before proceeding. Missing state validation enables OAuth CSRF attacks.

After completing social login, open DevTools → Application → Local Storage and Session Storage. The OAuth access/refresh token must not appear there. localStorage is accessible to all JS on the page, making it trivially stealable via XSS.

Create an account with email/password. Attempt social login with a provider using the same email. The app should either merge the accounts (with user confirmation), or prompt 'An account with this email exists — please log in with your password'. Silently creating a second account for the same email causes user confusion and data fragmentation.

Send N+1 failed login attempts in rapid succession (where N is the documented limit). Expect 429 Too Many Requests or account lockout. Without rate limiting, an attacker can attempt thousands of passwords per second via the login API.

Measure the response time for: a nonexistent email, a valid email with wrong password, and a valid email with correct password. The first two should be indistinguishable in timing. If 'user not found' returns in 10ms and 'wrong password' in 200ms (due to bcrypt), attackers can enumerate valid emails.

Note the session cookie value before login. Complete login. Assert the session cookie value has changed. Session fixation attacks plant a known session ID before the victim logs in, allowing the attacker to reuse that ID post-login without ever knowing the credentials.

Tab through every form field, submit, and navigate the flow without touching the mouse. All buttons must be reachable with Tab, activatable with Enter/Space, and focus must not become trapped outside of intentional modal dialogs.