Bug - @auth GraphQL @hasInverse Security Hole
@matthewmcneely is already working on this.
Since Jun 11, 2026.
- Dominant language
- Go
- Stars
- 21.8k
- Forks
- 1.6k
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 9
Description
https://discuss.dgraph.io/t/cant-update-node-to-create-edge-due-to-auth-rules/13061
https://discuss.dgraph.io/t/bug-auth-rules-of-parent-not-respected-when-child-with-hasinverse-is-added/12955/5
Even if you have an @auth rule on a node, the inverse node can still be created:
schema.graphql
type Foo
@auth(
add: { rule: "{$ROLE: { eq: \"ADMIN\" }}" }
delete: { rule: "{$ROLE: { eq: \"ADMIN\" }}" }
update: { rule: "{$ROLE: { eq: \"ADMIN\" }}" }
) {
id: String! @id
blas: [Bla!]! @hasInverse(field: foo)
}
type Bla {
foo: Foo
}
# Dgraph.Authorization {"VerificationKey":"totallysecret","Header":"Auth","Namespace":"lol","Algo":"HS256"}
mutation
mutation {
addFoo(input: [
{
id: "1234"
blas: []
}
]) {
numUids
}
}
query - Node was indeed created!
query {
queryFoo {
blas {
__typename
}
}
}
Update-Rules of parent should be respected when an inverse connection exists.
This is a HUGE security risk. However, as @amaster507 said, this may should not be fixed until the field-level-auth feature is implemented in order to protect the individual fields.
J
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.