“Internal” describes an endpoint’s current audience. It is not a security boundary.
Internal APIs often become dependencies for mobile apps, other teams, partners, automation scripts, and future services. If a request can reach an endpoint, that endpoint must be tested independently.
At minimum, verify:
- Authentication requirements
- Authorization and ownership boundaries
- Invalid input handling
- Supported HTTP methods
- Response code correctness
- Rate limiting
- Sensitive information disclosure
CORS should not be treated as protection for the API. It restricts certain browser requests but does not stop scripts, custom clients, or server-to-server communication.
Rentgen is not another general-purpose API client. It is an API discovery tool that starts with one working cURL request and systematically explores behavior beyond the expected path.
This is the first rule from The Power of Ten – Rules for Testing HTTP APIs: https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html
Top comments (3)
You correctly point out that labeling an API as “internal” doesn’t create a security boundary, so each endpoint should be treated as an attack surface during testing. Could you share how you decide which internal endpoints to fuzz first when you have a large surface area?
Great question. Prioritize endpoints that can change data or application state: POST, PUT/PATCH, and DELETE; read-only GET/QUERY endpoints come later.
That said, with Rentgen, the practical answer is often: test all of them. The configuration overhead is minimal: provide a working cURL request and map what each field represents. That's it; Rentgen can then systematically explore the endpoint’s behavior, including invalid inputs, authorization boundaries, method handling, and error responses.
So the priority helps when time is limited, but when the setup is that lightweight, there is little reason to leave endpoints untested.
Thank you, do you mind to check zyvop.com ?