VULNBANK API SECURITY ASSESSMENT

PART 2 — WHEN THE LOGIN API REVEALS TOO MUCH. Excessive Data Exposure and Rate-Limiting Weaknesses in VulnBank's Authentication Endpoint

Authentication endpoints are one of the most important security boundaries in an application.

They determine who gets access to the application, but they can also become a source of sensitive information disclosure and an entry point for automated attacks when security controls are insufficient.

After testing object-level authorization in Part 1, I shifted my attention to VulnBank's authentication endpoint.

The goal was to answer two questions:

What information does the API expose after a successful login?

and:

How effectively does the API control repeated authentication attempts?

The assessment identified two security weaknesses:

• API3: Broken Object Property Level Authorization / Excessive Data Exposure
• API4: Missing or insufficient observable rate limiting

Both issues were identified through hands-on testing using Burp Suite.

API3: EXCESSIVE DATA EXPOSURE

Target Endpoint

POST /login

POST /login

I began by submitting a normal login request using valid credentials.

The objective was not to bypass authentication.

Instead, I wanted to inspect the complete server response and determine whether the API was returning more information than the client actually required.

Observed Response

The API returned a successful authentication response containing a debug_info object.

The response exposed information including:

{
  "debug_info": {
    "account_number": "...",
    "is_admin": false,
    "user_id": "...",
    "username": "...",
    "login_time": "..."
  }
}

{
  "debug_info": {
    "account_number": "...",
    "is_admin": false,
    "user_id": "...",
    "username": "...",
    "login_time": "..."
  }
}

The response also contained authentication-related information required by the application.

However, the additional debug_info metadata was not necessary for completing the login operation.

What Was Exposed?

The response disclosed several properties associated with the authenticated user:

• Account number
• Internal user ID
• Username
• Administrative status
• Login timestamp

The issue here is not that the API returns information required for authentication.

The issue is that it also returns internal metadata that the client does not need.

An API should return the minimum amount of information required for the client to perform its intended function.

Why Is This a Security Problem?

At first glance, fields such as a username or login timestamp may not appear particularly sensitive. But API security should not be evaluated by looking at individual fields in isolation.

Information disclosed by one endpoint can become useful when combined with information obtained elsewhere.

For example, an exposed account identifier can become significantly more useful when an application also contains an object-level authorization vulnerability.

This is especially important in financial applications, where seemingly harmless metadata can provide additional context about users and their resources.

The principle is:

If the client does not need the property, the API should not expose it.

Impact

The immediate impact is unnecessary disclosure of account and internal user metadata to the client. Depending on what additional internal information is exposed, excessive data exposure can provide attackers with useful information for further enumeration or exploitation.

In this assessment, the evidence supports unnecessary property exposure.

I am not treating the exposed fields themselves as proof of account compromise. The security concern is that the API is returning information beyond what the client requires.

Remediation

Production API responses should contain only the properties required by the client.

Debugging information such as:

debug_info
internal IDs
internal state
development diagnostics

debug_info
internal IDs
internal state
development diagnostics

should not be exposed unnecessarily.

A safer response could look like:

{
  "message": "Login successful",
  "status": "success",
  "token": "..."
}

{
  "message": "Login successful",
  "status": "success",
  "token": "..."
}

The exact response structure depends on the application's requirements, but the principle remains the same:

Explicitly define what the client is allowed to receive.

Avoid returning complete backend objects simply because they are convenient to serialize.

API4: TESTING RATE LIMITING ON THE LOGIN ENDPOINT

Excessive data exposure was not the only thing I wanted to investigate.

Authentication endpoints are also common targets for automated attacks.

If an application accepts large numbers of authentication attempts without effective server-side controls, attackers may repeatedly attempt credentials for:

• Brute-force attacks
• Credential stuffing
• Automated password guessing
• Authentication abuse

So I tested the same /login endpoint for observable rate-limiting controls.

Testing Methodology

I used Burp Suite Intruder to submit a controlled sequence of invalid authentication attempts.

I configured Intruder to modify only the password parameter.

The test consisted of:

60 requests

The objective was to observe whether the application would:

• Start returning 429 Too Many Requests
• Lock the account
• Introduce an obvious delay
• Otherwise restrict repeated authentication attempts

Results

The results showed:

Requests:              60
401 Unauthorized:      60
429 Too Many Requests: 0
Account lockout:       Not observed
Obvious throttling:    Not observed

Requests:              60
401 Unauthorized:      60
429 Too Many Requests: 0
Account lockout:       Not observed
Obvious throttling:    Not observed

The response times also remained broadly consistent throughout the controlled test.

What Does This Tell Us?

The endpoint did not demonstrate an observable rate-limiting control during the controlled test. All 60 invalid authentication requests were processed and returned 401 Unauthorized.

There was no observed:

429 Too Many Requests

429 Too Many Requests

No account lockout was observed, and there was no obvious progressive throttling during the test. However, an important distinction needs to be made.

This test does not prove that the endpoint is vulnerable to denial of service. It also does not prove that absolutely no rate-limiting mechanism exists elsewhere in the infrastructure.

The evidence supports a narrower conclusion:

No effective, observable rate-limiting or authentication throttling control was encountered during the 60-request test.

That distinction matters when reporting security findings.

Potential Impact

If an authentication endpoint lacks effective server-side abuse controls, an attacker may be able to repeatedly submit authentication attempts.

This could increase exposure to:

Brute-force attacks

An attacker repeatedly tries different passwords against an account.

Credential stuffing

Previously compromised username/password combinations are automatically tested against the application.

Automated password guessing

Attackers can automate large numbers of authentication attempts without encountering an obvious restriction.

Authentication resource consumption

Large volumes of unnecessary authentication requests can consume application resources.

The actual severity depends on other controls implemented by the application and infrastructure.

REMEDIATION

Rate limiting should be implemented as a server-side security control for authentication endpoints.

Possible controls include:

1. Request rate limiting

Limit the number of authentication attempts allowed within a defined time window.

2. Progressive delays

Increase the delay between repeated failed authentication attempts.

3. Account-based protections

Detect repeated failures against individual accounts and apply appropriate protections.

4. IP/device-based controls

Identify abnormal authentication activity from a particular source and apply throttling where appropriate.

5. Monitoring and alerting

Repeated authentication failures should generate security telemetry that can be monitored and investigated.

6. Layered controls

Rate limiting should not be treated as the only authentication defense. It should complement strong password policies, secure authentication mechanisms, monitoring, and other anti-abuse controls.

Most importantly, these controls should be enforced server-side rather than relying on the client.

PUTTING THE TWO FINDINGS TOGETHER

At first, excessive data exposure and rate limiting may appear unrelated.

But both findings came from the same security boundary:

/login
                   |
        ┌──────────┴──────────┐
        ↓                     ↓
  Response security     Abuse protection
        ↓                     ↓
 Excessive metadata     No observable
                         throttling

/login
                   |
        ┌──────────┴──────────┐
        ↓                     ↓
  Response security     Abuse protection
        ↓                     ↓
 Excessive metadata     No observable
                         throttling

The first question was:

What does the API reveal after authentication?

The second was:

How does the API defend the authentication process against repeated attempts?

A secure authentication endpoint needs to address both. It should reveal only what the client requires and should implement appropriate server-side controls against automated abuse.

SECURITY LESSONS

This part of the assessment reinforced two important principles.

1. Minimize API responses

Just because information exists in a backend object does not mean it belongs in an API response.

Return only what the client actually needs.

2. Authentication needs abuse controls

Authentication security is not only about passwords and tokens.

The application must also control how aggressively an attacker can interact with the authentication mechanism.

CONCLUSION

The VulnBank /login endpoint demonstrated two security weaknesses during testing.

API3: Excessive Data Exposure

The successful login response exposed unnecessary account and internal user metadata through debug_info.

API4: Missing or insufficient observable Rate Limiting

A controlled sequence of 60 failed login attempts was processed without an observed 429, throttling, or account lockout.

The two findings highlight different sides of API authentication security:

Secure Authentication API
                |
        ┌───────┴───────┐
        ↓               ↓
   Minimize data    Control abuse
        ↓               ↓
  Don't expose     Rate-limit
  unnecessary      repeated
  properties       attempts

Secure Authentication API
                |
        ┌───────┴───────┐
        ↓               ↓
   Minimize data    Control abuse
        ↓               ↓
  Don't expose     Rate-limit
  unnecessary      repeated
  properties       attempts

The broader lesson is that securing an API is not simply about making authentication work. It is about controlling what the API reveals and how it can be abused.

In the next part, I will move from the authentication boundary to another server-side trust boundary:

Server-Side Request Forgery (SSRF).