Out of scope: Improper Input Validation Order on /api-internal/login via password field leads to unnecessary resource consumption

How it was found

Improper Input Validation Order (CWE-20) in Authentication Endpoint

Type: Architectural Security Issue
CWE: CWE-20 – Improper Input Validation
Severity: High

Summary

The /api-internal/login authentication endpoint in Burp Suite DAST (Enterprise) internal login interface (test instance) processes user-supplied input before enforcing field-level validation, allowing extremely large payloads in the password field to be buffered and parsed prior to rejection. Domain intentionally omitted for confidentiality.

This represents an architectural flaw in the request-handling pipeline, where validation occurs only after resource-intensive operations such as request buffering, memory allocation, and JSON deserialization.

The issue is not that large inputs exist, but that the system fully processes them before validation is applied.

Description

The authentication endpoint accepts a JSON body containing user credentials.

During testing it was observed that the application:

• accepts arbitrarily large values in the password field
• buffers the entire request body in memory
• performs full JSON parsing/deserialization
• only afterwards executes authentication logic and rejects the request

This behavior violates the fail-fast principle, where unreasonable or malformed input should be rejected as early as possible in the request pipeline.

Instead, the system performs expensive operations on untrusted input before applying validation, including:

• full request buffering
• allocation of large string objects
• JSON DOM parsing
• additional CPU and memory usage

The password field currently accepts input several orders of magnitude larger than any realistic password length.

Typical password sizes are generally within:

• 8–128 characters

However, the endpoint accepts multi-megabyte payloads before validation occurs.

There is no observable upper bound enforcement on the password field at the application level.

Affected Endpoint
POST /api-internal/login

Accessibility

• Unauthenticated
• Publicly reachable

Authentication endpoints represent a security boundary and should enforce strict validation to minimize processing of untrusted input.

Proof of Concept

The following request demonstrates that the endpoint accepts and processes an oversized password payload.

curl -X POST https://<target-instance>/api-internal/login \
  -H "Content-Type: application/json" \
  --data-binary @<(python3 -c '
payload = "A" * (10 * 1024 * 1024)
print(f\'{{"username":"admin","password":"{payload}"}}\')
')

This request sends a multi-megabyte password string which is accepted and processed before the authentication attempt is rejected.

Observed Behaviour

When submitting oversized input in the password field, the server processes the entire request body before returning a response.

The delay occurs during:

• request body buffering
• JSON parsing and deserialization
• allocation of large string objects in memory

After fully processing the payload, the application returns the standard authentication failure response:

{"code":2,"error":"Login failed."}

Requests exceeding upstream infrastructure limits are rejected earlier at the network layer. However, payloads below that threshold are still fully processed by the application before validation occurs.

This indicates that input size restrictions exist only at the infrastructure level and are not enforced at the application layer.

Root Cause

The issue is caused by an improper validation order in the request processing architecture.

Current flow:

Receive request
↓
Buffer entire request body
↓
Parse JSON payload
↓
Allocate large string
↓
Execute authentication logic
↓
Reject invalid credentials

Recommended fail-fast flow:

Receive request
↓
Validate Content-Length
↓
Validate field size constraints
↓
Parse JSON payload
↓
Execute authentication logic

In the current design, validation occurs after resource-intensive operations instead of before them.

Impact

Because validation occurs only after full request processing, the application performs unnecessary work when handling oversized input.

This leads to asymmetric resource consumption:

Client cost

• Sending a large text payload

Server cost

• Memory allocation
• JSON parsing
• CPU processing
• Garbage collection pressure

Although the request is eventually rejected, the server still performs significant processing on untrusted input beforehand.

This behavior:

• violates secure design principles for authentication endpoints
• increases resource usage when handling malformed input
• unnecessarily expands the attack surface of a security-critical component

Even if infrastructure-level limits prevent extremely large requests, the application still processes unnecessarily large inputs below that threshold.

Expected Counterargument

Counterargument

Request size limits are enforced by upstream infrastructure.

Response

Infrastructure-level limits do not replace the need for application-level validation.

Applications should enforce field-specific constraints (such as password length) rather than relying solely on global request size limits.

Additional Observations

• There is no legitimate use case for a password field to accept multi-megabyte input.
• This behavior indicates missing input validation controls in the authentication pipeline.
• The issue exists across multiple layers:
  • no early size validation
  • no field-level constraints
  • no fail-fast rejection

Recommendation

Enforce strict password length limits

Example:

• Maximum password size: 8192 bytes

Example validation:

if (password.length > 8192) {
    return HTTP 400;
}

Reject oversized requests early

Reverse proxies or load balancers should return:

• HTTP 413 Payload Too Large

based on Content-Length.

Apply fail-fast validation

Field constraints should be enforced before request buffering and JSON parsing whenever possible.

Avoid unnecessary request buffering

Large request bodies should not be fully processed before basic validation checks are performed.

Conclusion

The /api-internal/login endpoint contains an architectural flaw where validation is performed after resource-intensive operations.

As a result, oversized input is fully buffered and parsed before rejection, which violates the fail-fast principle and results in unnecessary processing of untrusted data.

Implementing early input validation and strict field size limits would align the authentication pipeline with modern secure development practices while reducing unnecessary resource usage.