API Security Testing

API security testing verifies that an API authenticates callers correctly, enforces authorization, validates untrusted input, limits abusive traffic, handles errors safely, and avoids exposing sensitive information. For a Java backend engineer, effective tests should exercise both expected requests and deliberate misuse.

Authentication tests verify that protected endpoints reject missing, malformed, expired, or otherwise invalid credentials. They should also confirm that credentials are not accepted in unintended locations or formats and that public endpoints remain intentionally accessible.

Authorization testing checks whether an authenticated caller can perform an operation on a resource they are actually permitted to access. Important cases include horizontal privilege escalation, where one user accesses another user's resource, and vertical privilege escalation, where a lower-privileged user invokes an administrative operation.

Input-security tests send unexpected, boundary, and malicious values through query parameters, path variables, headers, and request bodies. A Java service should validate inputs at trust boundaries and use safe data-access mechanisms such as parameterized queries rather than constructing database statements from raw input.

Security tests should also cover rate limiting, sensitive-data exposure, and error behavior. Responses should not disclose passwords, tokens, internal stack traces, database details, or unnecessary implementation information, while throttling should limit abusive request patterns without breaking legitimate traffic.

For automated Java testing, integration tests are particularly useful because they exercise the actual security configuration, filters, controllers, serialization, and persistence boundaries together. Tests should assert both the HTTP status and important response properties, because a correct status code alone does not guarantee that the response is safe.

Key points

• Test authentication separately from authorization.
• Verify object-level and role-based access controls with unauthorized identities.
• Treat every API input as untrusted and test validation boundaries.
• Check rate limits and security behavior under repeated requests.
• Assert that errors and successful responses do not leak sensitive data.

Interview questions

What security areas would you cover when testing a REST API?

I would cover authentication, authorization, input validation, rate limiting, sensitive-data exposure, and error handling. For authorization, I would test both access to another user's resources and access to privileged operations. I would also test malformed and boundary inputs across path, query, header, and body parameters. Finally, I would verify that failures do not reveal tokens, credentials, stack traces, or internal infrastructure details.

How would you test for broken object-level authorization?

I would create at least two users and resources owned by different users. After authenticating as user A, I would request user B's resource by changing the identifier while keeping the same authenticated session. The expected result is denial, typically with a `403` or an intentionally indistinguishable `404`, depending on the API's security design. I would repeat the test for update and delete operations because read protection does not imply write protection.

What is the difference between authentication and authorization, and how would you test each?

Authentication answers who the caller is, while authorization answers what that caller is allowed to do. Authentication tests include missing, invalid, expired, and valid credentials. Authorization tests use authenticated identities with different ownership or roles and verify that each protected operation has the expected permission boundary. A valid login therefore does not prove that the caller can access every endpoint or resource.

How would you test API rate limiting?

I would first establish the documented limit and its scope, such as per user, token, IP address, or endpoint. Then I would send controlled requests around the threshold and verify when throttling begins, what response is returned, and whether the server communicates retry information appropriately. I would also test that successful requests resume according to the defined policy and that one client cannot trivially bypass the intended control by changing an irrelevant request attribute. The test should run against an environment whose gateway and rate-limit configuration match the behavior being validated.

What should an API security test verify about error responses?

The response should communicate enough information for a legitimate client to handle the failure without exposing internal implementation details. I would check that unexpected exceptions do not expose stack traces, SQL fragments, filesystem paths, credentials, tokens, or infrastructure metadata. I would also verify that error formats are consistent and that authentication or authorization failures do not unnecessarily reveal whether protected resources exist. Tests should inspect both response bodies and relevant headers.