How do you implement permission-based authorization at the field level in a GraphQL resolver in NestJS?
Add a @ResolveField() for sensitive fields and check the requesting user's permissions inside the resolver. Return null when the user lacks permission. For ABAC-based field authorization, use CASL's ability.cannot() on the field name. This ensures sensitive data is never included in the response for unauthorized users.
- 1
Return null for unauthorized fields — never throw an error; GraphQL partial results are expected.
- 2
Declare the field as nullable: true in the schema so the null return is valid.
- 3
@ResolveField() is lazy — it only runs when the client explicitly requests that field.
- 4
Use GqlExecutionContext.create(context) in guards if applying field-level guards instead of resolver logic.
- 5
CASL ability.cannot('read', subject, 'fieldName') checks the third argument as a field condition.
Scenario Questions
0-2 years experience
- 1We have a NestJS GraphQL resolver that returns a User object. How would you restrict the email field so only admins can see it?
- 2If you add a custom decorator @Roles('admin') to a field resolver, what steps are needed to make it enforce permission at runtime?
2-5 years experience
- 1You need to add field‑level permission checks to several resolvers, but the same logic repeats. How would you refactor to avoid duplication, and what trade‑offs does your approach have?
- 2During testing you notice that a non‑admin user still receives the 'salary' field even though you added a guard. What could be causing this, and how would you debug it?
5-8 years experience
- 1Our service now serves millions of GraphQL requests per day, and field‑level checks are adding latency. How would you redesign the permission system to maintain security while improving performance?
- 2We have multiple microservices each exposing GraphQL schemas, and we need a consistent field‑level authorization model across them. What architecture would you propose, and how would you handle policy updates?
8+ years experience
- 1The product roadmap includes exposing the GraphQL API to third‑party partners with custom permission sets. How would you evolve the current NestJS field‑level authorization to support dynamic, tenant‑specific policies without a massive code rewrite?
- 2Legacy resolvers use inline if‑statements for permissions, and you want to migrate to a declarative, policy‑driven approach. What migration strategy would you use to minimize risk and ensure backward compatibility?
Follow-up Questions
- Can you walk me through the order in which NestJS executes guards and interceptors for a field resolver?
- How would you test your field‑level authorization logic?
- What are the security implications if you forget to apply the guard to a nested resolver?