Skip to main content
Authentication issues allow attackers to log in as other users, brute-force accounts, or bypass login entirely. These vulnerabilities are often trivial to exploit and have severe consequences.

​
default-accounts-present

Critical

​
What it is

The application accepts well-known default credentials that were never changed after deployment. Common defaults include admin/admin, admin/password, root/root, and admin/1234.

​
Why it matters

Attackers routinely try default credentials as the first step in reconnaissance. A single successful login grants full administrative access without any sophisticated attack.

​
How QAOS detects it

When the agent encounters a login form, it attempts authentication using a set of common default credential pairs: admin/admin, admin/password, root/root, admin/1234.

​
How to fix

Force credential changes on first login for any account created with default credentials. Remove or disable default accounts entirely in production. Conduct regular audits to ensure no accounts with default credentials exist.

​
default-credentials-in-dom

Critical

​
What it is

The page itself reveals default or factory credentials — through placeholder text, pre-filled form fields, inline HTML comments, visible text, or on-page help sections.

​
Why it matters

Revealing credentials in the DOM means any user who opens browser DevTools or views the page source can see them. No technical attack required.

​
How QAOS detects it

The agent inspects the DOM for visible credential hints: placeholder attributes, pre-filled value attributes on login fields, HTML comments, and visible text containing patterns like “default login”, “factory password”, or “use admin/”.

​
Examples

<!-- Credentials disclosed in placeholder -->
<input type="text" placeholder="admin" name="username">
<input type="password" placeholder="admin" name="password">

<!-- Credentials in HTML comment -->
<!-- default login: root/root -->

<!-- Credentials in visible text -->
<p>First-time login: use admin / admin123</p>

​
How to fix

Remove all credential hints from the DOM. Use generic placeholder text like “Username” and “Password”. Never include credentials in comments, help text, or pre-filled values on production pages.
Critical

​
What it is

Session cookies encode user identity in a way that can be predicted, decoded, or modified to impersonate other users. This includes base64-encoded user IDs, predictable patterns, or simple hashes of the username.

​
Why it matters

If an attacker can construct a valid session cookie for another user without knowing their password, they can take over any account on the platform.

​
How QAOS detects it

The agent analyzes session and authentication cookies for low-entropy values, base64-encoded content, timestamps, purely numeric values, or patterns that correlate with known user identifiers.

​
Examples

session=dXNlcjEyMw==      ← base64 decode: "user123" — trivially forgeable
auth_token=1708473600123  ← Unix timestamp — predictable
session_id=00001042        ← sequential numeric — enumerable

​
How to fix

Generate session tokens using a cryptographically secure random number generator with at least 128 bits of entropy. Never encode user identity directly into session tokens. Use a server-side session store that maps opaque tokens to user sessions. 
import secrets
session_token = secrets.token_urlsafe(32)  # 256 bits of entropy

​
no-password-spraying-protection

High

​
What it is

The login form does not protect against password spraying attacks — where an attacker tries a single common password across many different accounts, avoiding per-account lockouts.

​
Why it matters

Password spraying is one of the most effective credential attack techniques because it stays under per-account lockout thresholds. A single common password like “Summer2024!” may match a significant percentage of user accounts.

​
How QAOS detects it

The agent tests login forms by attempting the same password against multiple different usernames in rapid succession, observing whether the application detects or throttles this pattern.

​
How to fix

Implement rate limiting based on source IP and password value, not just username. Monitor for the same password being tried across multiple accounts. Consider CAPTCHA after a threshold of failures from a single IP, regardless of which username is targeted.

​
no-login-rate-limiting

High

​
What it is

The login form allows unlimited failed authentication attempts without lockout, progressive delays, or CAPTCHA challenges.

​
Why it matters

Without rate limiting, attackers can perform brute-force or credential stuffing attacks at high speed, eventually guessing valid credentials.

​
How QAOS detects it

The agent submits repeated invalid login attempts and observes whether the application responds with rate limiting (HTTP 429, lockout message, progressive delay, or CAPTCHA).

​
How to fix

Implement per-account lockout after 5–10 failed attempts. Add exponential backoff delays for repeated failures. Consider CAPTCHA after 3+ failures. Log and alert on unusual login attempt patterns.

​
compromised-credentials-accepted

High

​
What it is

The registration or password change form accepts credentials that are known to be compromised in public data breaches.

​
Why it matters

Credential stuffing attacks reuse leaked username/password combinations across services. If your application doesn’t check against known breached passwords, it’s vulnerable to automated attacks using breach databases.

​
How QAOS detects it

The agent attempts to register or change passwords using well-known compromised credential pairs from public breach datasets.

​
How to fix

Integrate with the Have I Been Pwned API (k-anonymity model) to check passwords against known breach databases at registration and password change time. Reject compromised passwords and prompt the user to choose a different one.

​
weak-password-accepted

Medium

​
What it is

The authentication system accepts weak passwords — fewer than 8 characters, or common passwords like 123456, password, or abc.

​
Why it matters

Weak passwords are trivially guessable by both human attackers and automated tools. Accepting them creates accounts that are easily compromised.

​
How QAOS detects it

The agent attempts to register or change passwords using weak test values: 123456, password, abc, and other common patterns.

​
How to fix

Enforce a minimum password length of 8 characters (12+ recommended). Reject common passwords. Consider using zxcvbn for strength estimation rather than simple length rules.

​
knowledge-based-password-recovery

High

​
What it is

The password recovery flow relies on personal knowledge questions — such as “mother’s maiden name”, “name of first pet”, or “city of birth” — to verify identity before allowing a password reset.

​
Why it matters

Answers to security questions are often publicly available through social media, data breaches, or social engineering. They provide a much weaker authentication guarantee than email or SMS verification, and cannot be changed once compromised.

​
How QAOS detects it

The agent navigates to the forgot-password or account-recovery flow and checks whether it prompts for personal knowledge questions before granting access or initiating a reset.

​
How to fix

Replace knowledge-based recovery with a time-limited, single-use token sent to a verified email or phone number. For high-assurance applications, require the user to confirm their identity through MFA before resetting credentials.

​
insecure-password-reset-process

High

​
What it is

The password reset process is vulnerable — the reset token is predictable, does not expire, or can be replayed. An attacker who intercepts or guesses a reset token can take over the account without knowing the original password.

​
Why it matters

Password reset flows are a high-value target because they bypass the primary credential. A weak reset process effectively removes the security of the password entirely.

​
How QAOS detects it

The agent triggers the password reset flow and inspects the reset token for predictability (sequential, short, timestamp-based). It also tests whether the token can be reused after the reset is complete.

​
How to fix

Generate reset tokens using a cryptographically secure random generator with at least 128 bits of entropy. Expire tokens after 15–60 minutes. Invalidate the token immediately after first use. Ensure tokens are scoped to a specific user and cannot be transferred. 
import secrets
token = secrets.token_urlsafe(32)  # 256-bit token, URL-safe

​
missing-mfa-sensitive-actions

High

​
What it is

Sensitive actions — such as changing a password, updating payment details, transferring funds, or modifying account recovery settings — complete after password-only authentication, with no second factor required.

​
Why it matters

If an attacker gains access to a user’s session (via XSS, session hijacking, or a compromised device), they can perform high-impact actions without any additional barrier. MFA on sensitive actions limits the damage of a compromised session.

​
How QAOS detects it

The agent identifies flows for sensitive operations (credential changes, payment modifications, account recovery settings) and attempts to complete them without a second authentication factor.

​
How to fix

Require step-up authentication (re-authentication or MFA challenge) before completing high-impact actions, even within an already-authenticated session. Common patterns include:
  • Re-entering the current password before changing it
  • Requiring an OTP from an authenticator app or SMS before payment changes
  • Sending an email confirmation link for changes to recovery contact details

​
weak-mfa-fallback-mechanism

High

​
What it is

When MFA is unavailable (lost device, expired backup code), the fallback recovery mechanism is weak — it relies on personal knowledge questions, a short static code, or a channel with insufficient assurance — allowing attackers to bypass MFA entirely.

​
Why it matters

MFA is only as strong as its weakest fallback. If an attacker can bypass MFA by answering a security question, the entire second factor is nullified. Fallback mechanisms are frequently the actual target of account takeover attacks.

​
How QAOS detects it

The agent navigates to the MFA challenge page and explores recovery/fallback options, checking whether they provide equivalent assurance to the primary second factor.

​
How to fix

Fallback mechanisms should be at least as strong as the primary MFA method:
  • Backup codes: single-use, high-entropy codes generated at MFA setup
  • Account recovery: require identity verification through a trusted channel (email link + account ownership proof)
  • Support-assisted recovery: require human verification with photo ID or similar
Never allow MFA bypass via security questions, short static PINs, or unauthenticated recovery flows.