API Security

Yes. GraphQL APIs are explicitly covered under Module C, with a distinct evaluation profile reflecting GraphQL’s single-endpoint architecture: query depth limits, query cost analysis, persisted-query discipline, introspection control, type-level and field-level authorisation, batching and alias-based authorisation bypass testing. The Scope Statement names the GraphQL schema (or schema version) in scope.

Module A evaluates web applications against the OWASP ASVS, with V13 (API and Web Service Interfaces) covering the web app’s calls to its backend APIs as part of the integrated product. Module C separately evaluates APIs as products in their own right, anchored in the OWASP API Security Top 10 — appropriate when the API surface is itself the product (developer platform, partner-integration API, BaaS rail). A SaaS that exposes both a customer-facing web UI and a public partner API would naturally combine Modules A and C on a single certificate, with the SaaS multi-tenant scope addressed by Module B.

Guardian currently evaluates against the OWASP API Security Top 10 (2023 edition) — categories API1:2023 through API10:2023. Where OWASP publishes a new edition, the change is reviewed by Guardian’s Technical Review Panel and adopted into GSA-PR-01 through a documented scheme-revision process. Existing certificates remain valid for their original cycle; recertification engagements use the version of the framework current at the time of recertification.

Yes. Where the certified API is a model-serving API, vector-database API, agentic-AI platform or similar, Module C’s evaluation profile includes AI/ML-specific concerns: input validation against prompt-injection vectors, rate limiting under inference cost (API4), output filtering for sensitive-data leakage, model-version disclosure controls, audit logging of inference requests/responses, and (for multi-tenant inference platforms) tenant-isolation evaluation in collaboration with Module B.

Source code review is sample-based at Level 2 (focused on authorisation enforcement, schema validation, authentication) and comprehensive at Level 3 (covering the in-scope codebase). Level 1 does not require source code access. Code review is conducted via secure remote access in your environment wherever feasible; source code is not retained by Guardian.

Where an API gateway (Kong, Apigee, AWS API Gateway, Azure API Management, Tyk, custom) fronts the certified API, evaluation specifically covers the gateway’s authentication and authorisation enforcement, rate limiting, request transformation hygiene, and the boundary between gateway and origin (gateway-bypass risk). The gateway product itself is not re-certified — that is governed by the gateway vendor’s own attestations — but its configuration and the integration boundary are in scope.

Yes. Where the certified product issues outbound webhooks, evaluation covers webhook signing (HMAC, JWT), timestamp / replay protection, retry semantics, customer endpoint validation, secret rotation, and delivery-failure handling. Customer-side webhook receiving endpoints are outside scope (they are not the certified product), but the platform’s outbound discipline is in scope.

Not in principle, but it does affect scoping and evaluation depth. Engagements with large endpoint counts are typically scoped to a representative sample plus full coverage of authentication, authorisation, schema and rate-limit machinery (which is shared across endpoints). For very large API surfaces, we may agree at scoping to scope-limit the certificate to a defined endpoint subset, with the boundary explicitly stated in the Scope Statement. Pricing is calculated per endpoint count and complexity.

The ‘Field of Accreditation’ is a high-level descriptor of the type of conformity assessment activity the body is accredited to perform. Guardian’s Field of Accreditation is ‘Product / Process Certification’, meaning we are accredited to certify products (and processes / services where applicable). This is distinct from ‘Management System Certification’ (ISO/IEC 17021-1), ‘Inspection’ (ISO/IEC 17020), and ‘Testing & Calibration’ (ISO/IEC 17025).

Module C produces an ISO/IEC 17065-accredited third-party certificate against the OWASP API Security Top 10 — the de facto international benchmark for API security. Specific regulatory acceptability depends on the regulator and any empanelment requirements (CERT-In empanelment is a separate accreditation under the Government of India). We are happy to discuss your specific regulatory driver at scoping; in regulated procurement processes, Module C certification typically serves as evidence alongside regulator-specific requirements rather than as a substitute for them.

Module C Level 1 is an accredited third-party certification — issued by an ISO/IEC 17065-accredited certification body, against a documented certification scheme (GSA-PR-01), with a public-directory listing, surveillance, complaints and appeals rights, and recognition through the international accreditation infrastructure. A VAPT report is a private, point-in-time technical assessment without those procedural attributes. Module C Level 1 includes VAPT as an evaluation activity, but it is the procedural infrastructure that makes the certificate procurement-grade.

Yes. Open-banking APIs (PSD2-style AISP/PISP, Indian Account Aggregator FIPs and FIUs, and equivalent regimes globally) are common Module C engagements. Module C provides an accredited attestation interpretable across the open-banking ecosystem; it is typically combined with regulator-specific empanelment / participant-onboarding requirements rather than serving as a substitute for them.

No. Module C evaluates the security of the certified API surface and the platform’s outbound discipline (signing, replay protection, secret rotation, etc.). Customer-side endpoints that receive your webhooks are outside the certified product boundary — those are governed by the customer’s own controls. We can, however, evaluate documented guidance the platform provides to customers for receiving webhooks securely.

The Scope Statement names the version (or version range) in scope. Where the API supports multiple co-existing versions (v1, v2, v3 reachable simultaneously), the Scope Statement names which versions are certified and which are not. Breaking changes that introduce new endpoints, new authorisation logic or new authentication paths trigger surveillance or re-evaluation activities outside the routine surveillance cycle, per the Certification Agreement and GSA-PR-01.

In our experience, yes — particularly where the buyer’s procurement process embeds API security questions (which is increasingly common in fintech, healthcare, and large-enterprise SaaS buyer ecosystems). A publicly-listed certificate that maps to OWASP API Top 10 categories produces interpretable evidence in security reviews. Whether it materially compresses overall procurement cycle time depends on the buyer’s process; presenting Module C certification at the start of a security review consistently shortens the back-and-forth.

Critical findings on the API surface — particularly under API1 BOLA, API2 Broken Authentication, or API5 BFLA — must be addressed for certification to be granted. Guardian issues the finding with technical detail and the relevant OWASP API Top 10 / GSA-PR-01 reference. Remediation is the applicant’s responsibility — Guardian does not provide consulting or fix-support. Guardian re-verifies corrective actions; one round of re-verification is included in the engagement, additional rounds are billed separately. If the API cannot meet the criteria, the certification is not issued, and there is no record of the failed application in the public directory.