Integrating GraphQL Schema Diffing with RBAC Validation: Detecting Access Drift in CI

GraphQL schema evolves fast — and sometimes, too fast. A single field addition can open up sensitive access if RBAC is not updated accordingly. This guide shows how to combine GraphQL schema diffing with RBAC static validation to detect access control drift before it reaches production. 1. Why Combine Schema Diff with RBAC Checks? Problem: A developer adds User.passwordHash to the schema, but forgets to restrict it in Hasura’s select_permissions. Boom — exposed in prod. Solution: Detect schema additions → cross-reference with RBAC rules → flag violations. 2. Tools Required graphql-inspector: detects schema diffs Custom RBAC linter (see previous article) GitHub Actions or GitLab CI 3. Step 1: Detect Schema Diff Add this to your workflow: npx graphql-inspector diff old-schema.graphql new-schema.graphql Output: + type User { + passwordHash: String + } Save this diff JSON for later processing. 4. Step 2: Extract Sensitive Additions Build a matcher script: const sensitiveFields = ['password', 'token', 'secret', 'key', 'hash']; function isSensitive(fieldName: string) { return sensitiveFields.some(keyword => fieldName.toLowerCase().includes(keyword)); } Filter diff for new fields on sensitive types (e.g., User, Session, AdminAuditLog). 5. Step 3: Check Against Hasura Metadata Use the RBAC CLI from previous article to: Load metadata from metadata/tables/.yaml For each added field, check: Is it exposed to any role? Is it restricted by column-level allowlist? Throw error if: New sensitive field is publicly accessible Added field exists but role user has columns: '' 6. CI Pipeline Example (GitHub Actions) - name: Check GraphQL Schema Diff run: npx graphql-inspector diff old.graphql new.graphql > diff.json - name: Run RBAC Diff Validator run: node check-rbac-diff.js diff.json metadata/ check-rbac-diff.js combines: graphql-inspector output YAML metadata parsing Sensitive field check Role × Column validation 7. Optional: Break Only on Sensitive Mismatch Allow normal schema additions, but fail only if: Field matches sensitive pattern RBAC does not explicitly filter it This avoids false positives while enforcing access discipline. Final Thoughts CI isn’t just for code — it’s for trust. Combining schema diffing with permission validation lets you catch high-risk mistakes before the merge button is clicked. Next: Auto-comment PRs with detected issues Slack alerting on security-drift Terraform-style plan/apply workflows for GraphQL security Graph the delta. Validate the access. Prevent silent leaks.

Mar 30, 2025 - 14:11

Integrating GraphQL Schema Diffing with RBAC Validation: Detecting Access Drift in CI

GraphQL schema evolves fast — and sometimes, too fast.

A single field addition can open up sensitive access if RBAC is not updated accordingly.

This guide shows how to combine GraphQL schema diffing with RBAC static validation to detect access control drift before it reaches production.

1. Why Combine Schema Diff with RBAC Checks?

Problem:

A developer adds User.passwordHash to the schema, but forgets to restrict it in Hasura’s select_permissions.

Boom — exposed in prod.

Solution:

Detect schema additions → cross-reference with RBAC rules → flag violations.

2. Tools Required

graphql-inspector: detects schema diffs
Custom RBAC linter (see previous article)
GitHub Actions or GitLab CI

3. Step 1: Detect Schema Diff

Add this to your workflow:

npx graphql-inspector diff old-schema.graphql new-schema.graphql

Output:

+ type User {
+   passwordHash: String
+ }

Save this diff JSON for later processing.

4. Step 2: Extract Sensitive Additions

Build a matcher script:

const sensitiveFields = ['password', 'token', 'secret', 'key', 'hash'];

function isSensitive(fieldName: string) {
  return sensitiveFields.some(keyword => fieldName.toLowerCase().includes(keyword));
}

Filter diff for new fields on sensitive types (e.g., User, Session, AdminAuditLog).

5. Step 3: Check Against Hasura Metadata

Use the RBAC CLI from previous article to:

Load metadata from metadata/tables/*.yaml
For each added field, check:
- Is it exposed to any role?
- Is it restricted by column-level allowlist?

Throw error if:

New sensitive field is publicly accessible
Added field exists but role user has columns: '*'

6. CI Pipeline Example (GitHub Actions)

- name: Check GraphQL Schema Diff
  run: npx graphql-inspector diff old.graphql new.graphql > diff.json

- name: Run RBAC Diff Validator
  run: node check-rbac-diff.js diff.json metadata/

check-rbac-diff.js combines:

graphql-inspector output
YAML metadata parsing
Sensitive field check
Role × Column validation

7. Optional: Break Only on Sensitive Mismatch

Allow normal schema additions, but fail only if:

Field matches sensitive pattern
RBAC does not explicitly filter it

This avoids false positives while enforcing access discipline.

Final Thoughts

CI isn’t just for code — it’s for trust.

Combining schema diffing with permission validation lets you catch high-risk mistakes before the merge button is clicked.