A city GraphQL API leaves introspection enabled in production, revealing the full schema to unauthenticated clients. What is the tester's best framing?
Select an answer to reveal the explanation.
Short Explanation
Publishing the blueprint of the building makes burglary planning easier. Production introspection hands attackers the schema map. Turn it down in prod and still test whether authz actually guards those fields.
Full Explanation
GraphQL introspection in production reveals the full schema to clients that should not receive a free attack map. A city API leaving introspection enabled for unauthenticated clients aids recon of queries, mutations, and types—then must still be paired with object-level authorization testing because hiding the schema alone does not enforce access control. Disable or tightly restrict introspection in production for municipal APIs.
Introspection is not required in every production deployment. It does not only affect offline documentation generators. Leaving it on does not enforce object-level authorization.
Exam caveat: defense is layered—restrict introspection and still test authZ on every sensitive field/mutation. CPTS API topics increasingly include GraphQL recon and authorization.
Operational check: disable introspection on production civic GraphQL (or restrict to admin networks), review schema for sensitive operations, test authorization on discovered fields within RoE, and monitor unusual GraphQL query shapes. Even with introspection off, continue authorization fuzzing of GraphQL mutations that touch citizen objects—obscurity is not access control. Schema hiding plus authZ testing together reduce GraphQL risk on city APIs.