Untrusted Data: The Root of Most Web Vulnerabilities

A large number of web vulnerabilities can be explained with one sentence:

The application trusted data it should not have trusted.

That data may come from a form field, URL parameter, JSON body, cookie, HTTP header, uploaded file, third-party integration, webhook, or even another internal service.

For a pentester or developer, understanding untrusted data is more important than memorizing payloads. Once you know where untrusted data enters the system, you can reason about injection, XSS, IDOR, SSRF, mass assignment, file upload bugs, and many other vulnerability classes.

Image: Type: Context, Mô tả: “A simple trust-boundary diagram showing user/browser/external API sending data into a web application, then to business logic, database, filesystem, and internal services.”. caption: “Untrusted data becomes dangerous when it crosses a trust boundary without validation, authorization, or encoding.”

What Is Untrusted Data?

Untrusted data is any data that the application cannot fully control.

Examples include:

• URL paths and query parameters
• Form fields
• JSON or XML request bodies
• Cookies
• HTTP headers
• Uploaded files
• JWT claims if not properly validated
• Webhook payloads
• Data from third-party APIs
• Data stored previously by another user

The key idea is simple: if a user, browser, client, partner, or external system can influence it, treat it as untrusted.

Untrusted does not mean malicious by default. It means the application must not assume the data is safe, authorized, correctly formatted, or semantically valid.

Why This Matters

Many applications are designed around happy paths.

A developer expects:

{
  "displayName": "Kevin",
  "email": "kevin@example.com"
}

But an attacker-controlled client may send:

{
  "displayName": "Kevin",
  "email": "kevin@example.com",
  "role": "admin",
  "isVerified": true
}

If the server blindly maps all fields into a user object, the problem is not the JSON format. The problem is misplaced trust.

Common Sources of Untrusted Data

1. Query Parameters

/search?q=laptop
/download?file=report.pdf
/profile?user_id=1024

Query parameters often control what data is retrieved, displayed, filtered, or downloaded.

Potential issues:

• SQL injection
• Reflected XSS
• Path traversal
• IDOR
• Open redirect
• Excessive data exposure

2. Request Body

{
  "productId": 1001,
  "quantity": 2,
  "price": 1
}

If the server trusts client-side values like price, role, discount, or ownerId, the application may become vulnerable to business logic flaws or mass assignment.

3. Cookies

Cookies are stored on the client side. Even if they look internal, they can often be modified by the user.

Dangerous assumptions include:

• Trusting isAdmin=true from a cookie
• Storing unsigned role information
• Using predictable session identifiers
• Missing HttpOnly, Secure, or SameSite flags

4. HTTP Headers

Headers such as Host, Origin, Referer, X-Forwarded-For, and Content-Type can influence application behavior.

Potential issues:

• Host header injection
• CORS misconfiguration
• Weak CSRF validation
• IP-based access control bypass
• Request parsing inconsistencies

5. Uploaded Files

Uploaded files are high-risk because they combine content, metadata, file names, and storage paths.

Potential issues:

• Unrestricted file upload
• Malware upload
• Path traversal through file names
• Stored XSS through SVG/HTML
• Remote code execution in poorly configured environments

Image: Type: Test case, Mô tả: “A local lab screenshot showing a file upload request in Burp Suite with filename, Content-Type, and file content highlighted.”. caption: “File upload requests contain multiple user-controlled surfaces: filename, MIME type, metadata, and content.”

How Untrusted Data Becomes a Vulnerability

Untrusted data becomes dangerous when it reaches a sensitive sink.

A sink is where data is used in a security-sensitive way.

Examples:

The basic mental model is:

Source -> Processing -> Sink

A pentester should track how untrusted data moves from source to sink.

Example: From Parameter to SQL Injection

Consider:

GET /products?category=books

If the backend builds a query like this:

SELECT * FROM products WHERE category = '<user input>'

The user-controlled value reaches a SQL query. If the application does not use parameterized queries, SQL injection may be possible.

The root cause is not merely a special character. The root cause is that untrusted data is treated as part of a trusted query structure.

Example: From Object ID to IDOR

Consider:

GET /api/invoices/7788
Authorization: Bearer token-for-user-A

If the user changes 7788 to another invoice ID and receives someone else’s invoice, the application has an authorization problem.

The root cause is not the use of numeric IDs. The root cause is that the server trusted the requested object ID without verifying ownership or permission.

Example: From Stored Input to Stored XSS

A user submits a display name:

Kevin

The application stores it and later renders it in another user’s browser.

If output encoding is missing, malicious HTML or JavaScript may execute.

This is important: stored data can still be untrusted. Data does not become safe just because it was saved to a database.

Defensive Controls

Validate Input

Validation checks whether data is expected.

Good validation is:

• Server-side
• Allowlist-based
• Type-aware
• Length-limited
• Business-rule aware

Example: if quantity must be an integer from 1 to 10, enforce that rule on the server.

Enforce Authorization

Input validation does not answer whether the user is allowed to access an object.

For object IDs, always verify:

• Does the object exist?
• Who owns it?
• What role does the current user have?
• Is this action allowed for this user on this object?

Use Context-Aware Output Encoding

For XSS prevention, output must be encoded based on where it appears:

• HTML body
• HTML attribute
• JavaScript context
• URL context
• CSS context

Encoding must match the output context.

Use Parameterized Queries

For SQL injection prevention, do not build queries by string concatenation. Use prepared statements or safe ORM patterns.

Avoid Client-Side Trust

Never trust client-side values for security decisions.

Examples of values that should be server-controlled:

• Role
• Permission
• Price
• Discount
• Account balance
• Ownership
• Approval status

Pentester Checklist

When reviewing a feature, ask:

• What data can the user control?
• Is the data validated server-side?
• Does the data reach a sensitive sink?
• Is authorization checked after authentication?
• Is output encoded based on context?
• Are dangerous fields accepted from the client?
• Can stored data affect other users later?
• Does the application trust headers, cookies, or hidden fields?

How to Practice Safely

Use lab platforms such as PortSwigger Web Security Academy, DVWA, or OWASP Juice Shop. Pick one feature and trace every piece of user-controlled data from request to response.

Do not start with payloads. Start with data flow.

Conclusion

Untrusted data is one of the most important concepts in web security. Vulnerabilities happen when applications allow untrusted data to influence queries, HTML output, filesystem paths, authorization decisions, internal requests, or business logic.

For pentesters, this concept improves pattern recognition. For developers, it improves secure design. For security teams, it provides a common language for explaining root cause.

References

• OWASP Web Security Testing Guide: https://owasp.org/www-project-web-security-testing-guide/
• OWASP Top 10:2025: https://owasp.org/Top10/2025/en/
• OWASP Cheat Sheet Series: https://cheatsheetseries.owasp.org/

Need Help?

KevinSec helps teams identify how untrusted data flows through web applications and APIs. If you want a practical security review focused on real attack paths, contact KevinSec through the Contact page.