API Gateway Audit

Different layer, different question. This audit reads the gateway's configuration — the policies, products, backends, identities and diagnostics that decide what is enforced before a request ever reaches your code. API Penetration Testing (/services/api-testing/) attacks the API itself: an engineer hunting broken object-level authorisation, business-logic flaws and data exposure in the application behind the gateway. API Stress Testing (/services/api-stress-testing/) measures how the whole path behaves under load. A gateway with a faultless policy set still fronts an API with an IDOR in it, and an API with perfect authorisation logic is still abusable if no product enforces a rate limit. Many clients run the audit first — it is quicker, and it closes whole classes of issue by configuration rather than by code change — then test the API behind it.

Azure API Management. Our tooling and methodology are built specifically for it, down to the policy elements and the management API version, and we would rather say so plainly than claim vendor-neutral coverage we cannot stand behind. If you run Kong, Apigee, AWS API Gateway or an appliance-based gateway, tell us at scoping and we will give you an honest answer about the depth we can reach on it, rather than sell you an Azure audit with the labels changed.

No. It is read-only: configuration is exported and analysed, nothing is written back, and no policy, product or role assignment is altered. We deliberately exclude load and denial-of-service testing so a shared pre-production environment is not disturbed. That does mean the audit evidences what the configuration says rather than what the gateway does under attack — where you need the second, an API penetration test is the right instrument, and the report says which of the two each finding rests on.

No. Named values and Key Vault secrets are read by name and metadata only — what exists, whether it is marked secret, whether it is Key Vault-backed rather than sitting in plain text, and whether it carries a rotation policy. We do not retrieve secret values, and we do not need to: the finding is that a logger connection string sits in a plain named value, not what the string says. Where we find a credential hardcoded into policy we report its location and enough context to identify it, and tell your named contact immediately rather than saving it for the report.

Yes, and it is often the sensible order — catching the gaps before the instance carries live traffic is the whole point. Be aware of what it does and does not evidence: a pre-production result is a statement about pre-production, and configuration drifts between environments precisely because each is changed by different people at different times. Where you put more than one instance in scope we audit each in its own right and set out where they have diverged. Where only one is in scope, the report states that limitation on its face rather than letting the result be read as covering both.

Then you receive the record of it, and that is a legitimate outcome rather than a wasted engagement. The report documents the controls that passed with the evidence behind each, alongside the layer coverage table — which is precisely the artefact that satisfies a client's due-diligence questionnaire, an ISO 27001 auditor or an insurer asking what protects your API estate. A low findings count on a well-run gateway is a result you can circulate, not a refund conversation.