Initial Setup: Create a legitimate first account (e.g., email: victim@gmail.com, password: Password123). Log out.
Re-register: Create a new account using the exact same email (victim@gmail.com) but a different password (e.g., AttackerPass999).
Verification: Try to log in using victim@gmail.com and the new password (AttackerPass999). If the application allows the process to finish successfully without throwing an “Email already exists” error, you have takeover the original account.
Variation: Case Sensitivity Bypass
Sometimes developers check for duplicates using exact string matching but store data in a case-insensitive collation database.
Test: If abc@gmail.com exists, try registering as Abc@gmail.com or aBc@gmail.com. If the backend treats these as different during the check but the same during storage, you might trigger an overwrite or create a “shadow” duplicate account.
In the Password field (or sometimes the Username field), enter an extremely long string of characters (e.g., 10,000+ ‘A’s). You can generate this easily in a text editor or using Python: python -c “print(‘A’*20000)”. and Submit the form.
Monitor the response time. If the request hangs for a long time and eventually returns a 500 Internal Server Error, it indicates the server struggled to process the input, suggesting a vulnerability.
Fill out the signup form with generic details and submit it, intercepting the request in a proxy tool like Burp Suite.
Send the captured POST request to Burp Intruder.
In the Intruder “Positions” tab, clear existing payload markers. Add markers (§§) around the email parameter value. Example: email=testuser§1§@example.com
In the “Payloads” tab, choose “Numbers” (e.g., from 1 to 1000) or provide a list of different email addresses and Start the attack.
Analyze the results. If you receive a 200 OK (or whatever the success response code is for hundreds of consecutive requests without being blocked or presented with a CAPTCHA, the endpoint lacks rate limiting.
This category covers general security best practices that are often ignored during the signup process.
Allows Disposable Email Addresses:The application should block domains from known temporary email providers (e.g., Mailinator, TempMail). Allowing these invites abuse, spam, and ban evasion.
Registration Form on non-HTTPS:If the signup page is served over HTTP, all data entered including the new password and personal information is transmitted in plaintext and can be intercepted by a Man-in-the-Middle attacker. you can also test by replacing https:// with http:// manually.
A signup form must enforce a strong password policy to protect users from brute-force or credential-stuffing attacks later on.
How to Test:
Determine how strong the password policy is by evaluating the length, complexity, reuse, and aging requirements of passwords.
Observe that it’’ possible to set common passwords, such as password or 123456.
Vulnerabilities:
Weak Password Policy.
Check for the following weaknesses:
Easily Guessable Passwords: Does the form accept passwords like 123456, password, qwerty, or admin?
Username as Password: Does the form allow the password to be identical to the username? This is a very common pattern for lazy users.
Email as Password: Does it allow the password to be the same as the email address?
Improper Password Recovery: While technically part of the login flow, the foundation is laid at registration. Ensure the mechanism for future password resets (e.g., security questions set during signup) is secure and not easily guessable.
Remediation:
Introduce additional authentication controls (i.e. two-factor authentication) or introduce a strong password policy.
If an application hosts user profiles on the root path (e.g., site.com/{username}), an attacker can potentially “take over” critical system pages by registering a username that matches a system endpoint or filename.
Steps to Reproduce:
Identify URL Pattern: Confirm that user profiles are accessible directly via target.tld/username.
Register Reserved Names: Attempt to signup with usernames corresponding to critical pages or files.
Modern Apps: login, admin, signup, api, dashboard.
Server-Side Validation Bypass (Client-Side Only Checks)
A lot of applications rely heavily on client-side validation to enforce rules like password length, allowed characters, field formats, and required inputs. The problem is that anything enforced only in the browser can be bypassed easily with a proxy or a modified request. If the backend isn’t validating properly, attackers can push malformed or dangerous data into the system.
Steps to Reproduce:
Open the signup page and fill in the fields with any data.
Intercept the outgoing request using Burp Suite, OWASP ZAP, or a browser extension like Tamper.
Modify parameters that would normally be blocked by frontend rules.
Examples:
Empty username or email
Password shorter than the minimum requirement
Invalid email format (e.g., test@test, a@b, abc)
Special characters in fields that normally block them
4. Forward the request to the server.
If the registration still succeeds despite breaking the frontend rules, the server lacks proper validation. This can lead to malformed accounts, stored XSS, broken workflows, or even injection vulnerabilities.
Some applications expose multiple signup endpoints due to older versions, admin flows, mobile APIs or legacy functionality. These endpoints sometimes skip validations, email verification or business logic checks.
Steps to Reproduce:
Spider or crawl the application.
Look for endpoints like:
3. Compare the validation rules between each endpoint.
If any alternate endpoint allows registration without proper checks (like no email verification, no rate limiting, no password rules), it becomes an easy target for abuse.
HTTP Parameter Pollution (HPP) becomes dangerous when the backend doesn’t clearly define how duplicate parameters are handled. Attackers can inject extra parameters to override existing values or sneak values past validation.
Steps to Reproduce:
Intercept the signup request.
Add multiple values to the same parameter. Example:
3. Forward the request.
If the server picks the wrong value or inconsistently processes it, you may trigger: Account takeover, Bypassed validation, Confusing or corrupted user records..
Internationalized domain names allow characters from different languages. The problem is that many Unicode characters look identical to normal English letters, even though they’re completely different under the hood. This opens the door for signup and password-reset bypasses when apps normalize emails incorrectly.
If the app treats both as the same after normalization, you can use the Unicode version during signup or password-reset and take over the legitimate account. For the full walkthrough with screenshots and PoC steps, you can check out the detailed article on this method.
4. Look for HTTP headers or messages indicating lockout.
If OTPs can be brute-forced, an attacker can complete signup for any email or number without owning it. This breaks the trust model of verification entirely.
Many systems issue an initial session token during registration and continue using it through verification, onboarding, and first login. If the token is not regenerated, attackers can preload a session and force victims into it.
Steps to Reproduce:
Start a signup flow and capture the session cookie.
Complete verification and onboarding.
Compare the session token before and after verification.
Try registering multiple accounts without refreshing your token.
Attempt to reuse the same token across different accounts or devices.
If the session stays the same, it’s vulnerable to session fixation or hijacking. The signup process becomes a takeover vector.
Some backend systems still improperly handle null bytes in strings, causing truncation or unsafe transformations. If validation happens before the null byte but storage happens after, attackers can bypass rules or corrupt user data.
Some applications allow users to sign up and log in without confirming ownership of their email. This flaw lets attackers register accounts with any email and impersonate other users.
Steps to Reproduce:
Register using a random email.
Skip the confirmation link.
Try logging in directly.
Attempt actions like profile update or password reset.
If the app treats the account as fully active without verifying the email, it is vulnerable.
If the server does not rotate the session ID during signup, attackers can force victims into attacker-controlled sessions and take over their freshly created accounts.
Steps to Reproduce:
Start a signup flow and save the session ID.
Complete signup and verification.
Compare the session ID before and after the process.
Try accessing the account using the original ID.
If the ID stays the same, the platform is vulnerable to session fixation.
Finding Mass-Assignment Bugs in JSON-Based Registration Flows
APIs that accept JSON during registration are particularly prone to mass-assignment and parameter tampering issues. Attackers can add unexpected fields or alter parameter shapes and casing to influence server-side logic (for example, granting themselves elevated roles, joining organizations, or bypassing verification). I’ve covered all the JSON-based signup manipulation techniques in the next article, so you can dive deeper there.