Beyond the Frontend: API Recon and Hidden Attack Surfaces

Introduction

Modern web applications rarely operate as a single monolithic system. Behind the interface that users interact with, APIs continuously exchange data between the frontend, backend services, databases, and other components.

From a security perspective, this creates an important question: How much of the application's real attack surface is actually visible through the frontend?

The answer is often: not all of it.

A web application may expose only a small subset of its API functionality through the user interface. An endpoint that appears to be used only for retrieving information may support additional HTTP methods. An API may accept content types that are never used by the frontend. Responses may reveal fields that users are not normally allowed to modify. Error messages may even provide clues about internal API requests that are never directly exposed to the client.

This is why API security testing should go beyond simply replaying the requests generated by the frontend.

A thorough API assessment involves understanding how the API behaves, identifying its endpoints, discovering supported HTTP methods and content types, looking for hidden functionality, and analyzing the information returned by the server.

In this article, we will follow a practical API security testing methodology that starts with reconnaissance and gradually moves toward hidden endpoint discovery and content-type analysis.

The goal is not simply to find more endpoints. The goal is to understand the real attack surface behind the application.

1. Understanding the API Attack Surface

Before testing an API, we first need to understand what we are actually looking for.

An API provides a way for different software components to communicate and exchange data. In a web application, the frontend may use APIs to retrieve products, update user information, process orders, or perform other operations.

For example, a browser might send:

GET /api/books HTTP/1.1 Host: example.com

At first glance, this appears to be a simple request that retrieves a list of books.

But from a security testing perspective, several questions immediately arise:

· Are there other endpoints related to /api/books?

· What parameters does the endpoint accept?

· Which HTTP methods are supported?

· Does the API accept only JSON?

· Does it also process XML or other content types?

· Are there undocumented endpoints?

· Does the API expose fields or functionality that are not present in the frontend?

These questions form the foundation of API reconnaissance.

The first step in API security testing is therefore to identify the API's attack surface.

1.1 Finding API Endpoints

The first objective is to discover as many relevant API endpoints as possible.

Some endpoints are obvious because they are directly used by the frontend:

GET /api/books GET /api/products GET /api/users/123 POST /api/checkout

However, not every API endpoint is necessarily exposed through the user interface.

Some APIs may be used directly by other services, administrative interfaces, mobile applications, or internal components. Others may simply be undocumented.

This is why API reconnaissance should include several sources:

· HTTP traffic generated by the application

· Burp Suite HTTP History

· Application crawling

· JavaScript files

· API documentation

· Common API paths

· Naming patterns discovered during reconnaissance

The objective is to build a map of the API before moving on to deeper testing.

1.2 Looking for API Documentation

API documentation can provide a significant amount of information about an application's attack surface.

Common locations may include:

/swagger/ /swagger/index.html /openapi.json /api-docs/

Even when documentation is not publicly advertised, it may still be referenced by the application itself.

For example, JavaScript files or application configuration may contain references to API documentation or OpenAPI specifications.

Finding documentation can reveal:

· Available endpoints

· HTTP methods

· Required parameters

· Optional parameters

· Request formats

· Response structures

However, documentation should never be considered the complete source of truth.

The actual API implementation may support functionality that is missing from the documentation.

That is why documentation discovery should be combined with direct testing of the API.

1.3 Exploring the Base Path

When an endpoint is discovered, do not always stop at the exact path you found.

Suppose reconnaissance reveals:

/api/swagger/v1/users/123/

It may also be useful to investigate higher-level paths such as:

/api/swagger/v1/ /api/swagger/ /api/

The reason is simple: documentation, configuration files, or other API resources may exist at a higher level of the path hierarchy.

This is a small but useful reconnaissance technique.

The broader lesson is:

When you discover one endpoint, think about the API structure around it — not just the endpoint itself.

2. Don't Trust the HTTP Method You See

One of the most important lessons in API testing is that the HTTP method observed in the frontend does not necessarily represent all functionality supported by the endpoint.

Suppose the application sends:

GET /api/products/3/price

The frontend may appear to use this endpoint only to retrieve the product price.

But the next question should be:

Does this endpoint support other HTTP methods?

A useful first step is to send an OPTIONS request:

OPTIONS /api/products/3/price

A response may contain:

Allow: GET, PATCH

This immediately changes our understanding of the endpoint.

The endpoint is not necessarily read-only. It may also support PATCH.

At this point, the tester can investigate the PATCH behavior in an authorized testing environment and determine whether authentication or additional controls are required.

The key lesson is:

UI functionality does not always equal API functionality.

The frontend may expose only one operation while the underlying API supports additional operations that are not directly visible to the user.

2.1 Testing HTTP Methods

Common HTTP methods worth considering during API testing include:

GET — Retrieve information POST — Create or submit data PUT — Replace a resource PATCH — Partially modify a resource DELETE — Remove a resource OPTIONS — Identify supported methods HEAD — Retrieve headers without the response body

The objective is not to blindly send every method. The objective is to understand which methods the server actually supports and whether authorization is consistently enforced.

Burp Suite Repeater is useful for manually changing the HTTP method and comparing responses.

For example:

GET /api/users/5 POST /api/users/5 PUT /api/users/5 PATCH /api/users/5

Differences in status codes, response lengths, headers, or error messages can reveal additional functionality.

A method that returns 405 Method Not Allowed is different from a method that returns 401 Unauthorized. The first suggests the method is not allowed at that endpoint, while the second may indicate that the functionality exists but requires authentication.

2.2 Finding Unused API Endpoints

A particularly interesting case occurs when an endpoint is used by the application for one purpose but supports functionality that is not exposed by the frontend.

Consider:

GET /api/products/3/price

If OPTIONS indicates:

Allow: GET, PATCH

then the PATCH method becomes an interesting candidate for further investigation.

The response to an unauthorized PATCH request may also provide useful information. For example, an error such as:

Unauthorized

may indicate that the method exists but requires authentication.

Further error messages can reveal additional requirements, such as an expected Content-Type or a required parameter.

This creates a practical workflow:

1. Discover an endpoint through normal application usage.

2. Test supported HTTP methods.

3. Identify methods that are not used by the frontend.

4. Analyze authorization behavior.

5. Use error messages to understand request requirements.

6. Test the behavior only within an authorized scope.

This approach turns a simple API request into a broader investigation of the endpoint's functionality.

3. Content-Type: The Same Endpoint, Different Behavior

Many APIs expect data to be submitted in a specific format. The Content-Type header tells the server how the request body should be interpreted.

Common examples include:

Content-Type: application/json Content-Type: application/xml Content-Type: text/xml Content-Type: application/x-www-form-urlencoded Content-Type: multipart/form-data Content-Type: text/plain

During API testing, it is useful to determine whether an endpoint accepts more than one format.

For example, an endpoint may normally receive:

Content-Type: application/json

with a JSON body.

In some implementations, the same logical data may also be accepted as XML.

The important point is that different parsers and processing paths can produce different security behavior.

A change in Content-Type may reveal:

· Information disclosure

· Different validation behavior

· Inconsistent security filtering

· Different parser behavior

· Unexpected server-side processing

Therefore, Content-Type is not merely a formatting detail. It can be part of the API's security boundary.

3.1 JSON vs XML

Consider a simplified example.

A JSON request might produce:

403 Forbidden

while changing the request to XML could result in a different response, such as:

200 OK

Or a normal JSON request may return a generic error:

Invalid credentials

while an XML request may expose a parser-specific error:

XML parser error at line 3

Such differences can provide valuable information about how the backend processes requests.

The goal of this testing is not to assume that XML is inherently insecure or that JSON is inherently secure. Instead, the goal is to identify inconsistent behavior between different processing paths.

If the application uses different parsers or validation logic for different Content-Types, the security controls applied to one format may not necessarily be identical to those applied to another.

This is why Content-Type variation should be considered during API security assessments.

3.2 Using Content-Type Converter

When testing JSON and XML representations, manually converting request bodies can be time-consuming.

A Burp Suite extension such as Content Type Converter can help convert compatible requests between formats and update the corresponding Content-Type header.

For example, a request such as:

{ "username": "admin", "password": "123" }

may be represented as XML:

admin 123

The purpose is to compare server behavior across representations and identify unexpected differences.

As always, this type of testing should be performed only against systems for which you have explicit authorization.

4. Hunting for Hidden API Endpoints

Finding a few endpoints during reconnaissance does not mean the API surface is fully mapped.

Developers often use consistent naming conventions. If you discover:

/api/user/update

you might reasonably investigate whether related operations exist, such as:

/api/user/delete /api/user/create /api/user/export /api/user/search

Burp Intruder can help automate this type of enumeration in an authorized testing environment.

A simplified example is:

PUT /api/user/§FUZZ§

with candidate words such as:

update delete create export search archive import reset

The results should then be analyzed carefully.

A successful discovery is not always indicated by a 200 response. A 401, 403, or another non-404 response can also be interesting because it may indicate that the endpoint exists but requires authentication or authorization.

The goal is to distinguish between:

Endpoint does not exist

and:

Endpoint exists but access is restricted.

4.1 Response Analysis

When analyzing endpoint enumeration results, do not look only at the HTTP status code.

Other useful signals include:

· Response length

· Response headers

· Content-Type

· Response time

· Error messages

· Redirect behavior

For example:

/delete → 401, length 120 /archive → 401, length 125 /random → 401, length 45

Although all three responses have the same status code, their differences may justify further investigation.

The important lesson is that API reconnaissance is often about comparing behavior rather than looking for one specific response code.

Small differences can become valuable clues when viewed in context.

5. A Practical API Testing Workflow

The techniques discussed in this article can be combined into a structured workflow:

7. Discover the API

8. Identify endpoints

9. Look for documentation

10. Explore base paths

11. Identify supported HTTP methods

12. Test methods that are not visible in the frontend

13. Identify supported Content-Types

14. Compare server behavior across representations

15. Enumerate potential hidden endpoints

16. Analyze response differences

This workflow helps transform API testing from a collection of isolated tricks into a repeatable methodology.

The central idea is simple:

Do not test only what the frontend shows you.

Instead, investigate what the API actually supports.

6. Key Takeaways

· The frontend does not necessarily expose the complete API attack surface.

· Finding one endpoint should lead to questions about related endpoints and higher-level paths.

· HTTP methods should be tested and compared rather than assumed from frontend behavior.

· OPTIONS can provide useful information about supported methods, although its output should not be treated as definitive proof of the entire server-side implementation.

· Different Content-Types can trigger different parsers and processing paths.

· API endpoint enumeration should consider status codes as well as response length, headers, and error behavior.

· Error messages and response differences can provide valuable reconnaissance clues.

· API security testing is fundamentally about understanding behavior, not simply sending payloads.

Conclusion

API security testing begins with reconnaissance.

Before looking for complex vulnerabilities, it is important to understand what the application actually exposes, what the API supports, and what functionality may exist beyond the frontend.

By systematically identifying endpoints, exploring base paths, testing HTTP methods, comparing Content-Types, and hunting for hidden endpoints, we can build a much more complete picture of the application's attack surface.

But discovering the API is only the beginning.

The next question is even more interesting:

What happens when an API accepts parameters or data that the developer never intended the client to control?

In Part 2, we will move from API reconnaissance to API logic and explore Mass Assignment and Server-Side Parameter Pollution. We will see how API responses and backend error messages can reveal hidden parameters and internal application behavior