Improper access control leads to unauthorized access to user data by modifying object identifiers like user IDs, order numbers, or file references.

Application blindly trusted the Host header, leading to redirection to an arbitrary domain.

User input is reflected in responses without sanitization, leading to script execution.

Malicious scripts are stored on the server and executed when viewed by users.

Unvalidated SQL input allows attackers to manipulate queries and access unauthorized data.

Application config file accessible via direct URL, revealing internal settings.

User input is rendered as HTML, which can deface the page or create misleading elements.

Sensitive pages accessible directly without authentication or role validation.

Application uses unencrypted HTTP, exposing data to interception.

System accepts weak passwords lacking length or complexity requirements.

Session remains valid even after logout, allowing re-use of token.

Cookies lack security attributes, increasing risk of theft via XSS or MITM.

Form fields can be modified to perform actions as another user.

Web server displays list of files, which may include sensitive content.

Attacker sets a session ID for the victim, allowing session hijack after login.

SQL errors are displayed to the user, exposing query structure.

Application can be loaded in an iframe, tricking users into clicking hidden UI.

Password reset logic can be manipulated to control other accounts.

Redirects use unvalidated user input, potentially sending users to malicious sites.

Lack of CSP allows broader scope for XSS and injection.

App exposed via uncommon HTTP ports, potentially overlooked during testing.

Short HSTS period weakens protection against SSL stripping.

Lack of rate-limiting allows spamming OTPs to user phone/email.

Login has no protection against repeated failed attempts.

Application allows uploading of executable or web-accessible files.

Database is exposed without authentication on public network.

Server sends DNS queries to attacker-controlled domains (e.g., SSRF detection).

Key used for encryption is exposed in client-side JS files.

Camunda dashboard is accessible and may allow brute-force login attempts.

Tomcat Manager interface is exposed, often with default creds.

Default Tomcat landing page indicates default configuration.

User input is not validated or sanitized properly.

JSON config file exposed via direct access reveals credentials or internal paths.

API documentation publicly available, exposing internal endpoints.

Application does not enforce HTTPS via HTTP Strict Transport Security.

System metrics page is accessible and may reveal infrastructure data.

Short description not found.

Reveals WordPress version and license info — useful for attackers.

Exposes version info and system details.

Login page accessible publicly, allows brute-force and enum attacks.

WordPress REST APIs are accessible and may leak data.

XML-RPC enabled, allowing brute-force via pingbacks.

Host header is not validated, causing open redirection.

Short description not found.

Short certificate life may indicate misconfiguration or impending expiration.

Captcha bypass possible due to visible encoded text.

API key exposed and vulnerable to abuse (e.g., map queries, billing).

Endpoints accept unauthenticated requests with no token checks.

Users can change password without being logged in.

Attacker changes object ID to escalate or manipulate data.

API URLs visible in frontend JS files give insight into backend structure.

API help documentation exposed without access control.

Key is directly retrievable via a GET endpoint.

HTML contains commented URLs pointing to internal apps.

Raw SQL passed through parameters without validation.

ASP.NET stack trace and errors disclosed to end users.

Usernames can be enumerated via /wp-json/wp/v2/users.

Tokens, credentials, or user data printed in server logs.

Downloadable links return empty or placeholder files, often unused.