Use public SDK integration tests to find API coverage questions
A well-tested API can still leave you unsure where to investigate next. Compare its exposed operations with the vendor’s public SDK integration tests, then inspect what those tests actually assert. The result is a list of coverage questions you can investigate within an authorized scope.
The starting assumption in one review was that the system was well tested, so ordinary scenarios were unlikely to reveal much. Reading the SDK tests changed the next question: which behaviors did this particular suite demonstrate? That comparison produced candidate leads. It did not provide a complete coverage audit or confirm a vulnerability.
Build an operation inventory before searching tests #
Start with the documented API operations available to the account or environment under review. Record the API version and the SDK release or commit beside that inventory. An operation introduced after the SDK release should not be counted as an unexplained omission.
Map each operation to SDK methods and then to integration tests. Follow wrappers and shared fixtures; a test name does not have to match an operation name. Keep unresolved mappings marked as unknown.
Text searches help locate candidates, but they do not measure runtime coverage. A matching method name might appear only in setup, a comment, or an assertion about a mock. A missing name might be hidden behind a helper or parameterized test. Check whether each test calls the service, what inputs it supplies, and which results it verifies.
Record assertions, not just test presence #
This clean-room fixture is invented. Its operation names and test behavior do not describe any real service:
| Operation | Evidence in the fictional public suite | Next coverage question |
|---|---|---|
create_item | Creates an item and asserts that an ID exists | Does an invalid field produce the documented rejection? |
update_item | Updates an item owned by the test account and reads it back | Does a different test account lack permission to update it? |
get_item | No direct test located; helper usage unresolved | Does a shared fixture exercise retrieval and assert its result? |
The last row stays unresolved until someone reads the helper. It would be premature to label it “untested.”
For each mapped test, note its credentials’ role without recording secrets, fixture ownership, expected failure behavior, and assertions. A successful request under one account says little about authorization under another. A negative test that merely catches any exception may pass on a network failure without demonstrating the intended denial.
Use precise notes such as “no assertion for this behavior found in the inspected public suite.” Vendors may have private service tests, separate security suites, or tests in another SDK. Public test omissions cannot prove those checks are absent.
Follow the data to its consumer #
A coverage gap can justify a closer look at an input field if an API accepts and returns a string, which proves only acceptance and retrieval. Storage may legitimately preserve arbitrary text.
For a rendering-related hypothesis, maintain a small dataflow record: input field, stored representation, consuming component, output context, and observed handling. The consumer determines whether it treats the string safely. An API response alone cannot demonstrate unsafe rendering or a security impact.
Before any live follow-up, confirm the allowed scope, test accounts, and rate limits; use owned test data and the least disruptive check that answers the question.
If the consumer cannot be inspected or exercised within that scope, leave the hypothesis unresolved. Do not turn a stored value into a vulnerability claim to make the investigation sound complete.
Verify the map before choosing a lead #
Have another pass through the fixtures and shared helpers, reconcile SDK and API versions, and separate source inspection from tests actually executed. For every proposed follow-up, write down the missing assertion and the observation that would settle it.
Pick one unresolved row in your own operation map and trace it through the test’s assertions before sending another request.