Security: Server-Side Request Forgery (SSRF) in GraphQL Handler#347
Security: Server-Side Request Forgery (SSRF) in GraphQL Handler#347tomaioo wants to merge 1 commit into
Conversation
The `data-driven-dependencies/pages/api/graphql.js` handler reads the `source` field from user-provided request body and passes it directly to the `graphql` function without validation. While it uses a queryMap for `id`-based lookups, when `requestParams.id` is not provided, it falls back to `requestParams.query` which allows arbitrary GraphQL query execution. More critically, the `queryMap` lookup uses unsanitized user input as a key, and the file path construction in `getConfig().serverRuntimeConfig.projectRoot` combined with `path.resolve` could potentially be exploited if `projectRoot` is manipulated. The main concern is that this endpoint appears to be an internal API but doesn't validate the origin, allowing potential SSRF if the GraphQL schema has introspection enabled or if there are internal-only mutations. Signed-off-by: tomaioo <203048277+tomaioo@users.noreply.github.com>
|
Hi @tomaioo! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
Summary
Security: Server-Side Request Forgery (SSRF) in GraphQL Handler
Problem
Severity:
High| File:data-driven-dependencies/pages/api/graphql.js:L1The
data-driven-dependencies/pages/api/graphql.jshandler reads thesourcefield from user-provided request body and passes it directly to thegraphqlfunction without validation. While it uses a queryMap forid-based lookups, whenrequestParams.idis not provided, it falls back torequestParams.querywhich allows arbitrary GraphQL query execution. More critically, thequeryMaplookup uses unsanitized user input as a key, and the file path construction ingetConfig().serverRuntimeConfig.projectRootcombined withpath.resolvecould potentially be exploited ifprojectRootis manipulated. The main concern is that this endpoint appears to be an internal API but doesn't validate the origin, allowing potential SSRF if the GraphQL schema has introspection enabled or if there are internal-only mutations.Solution
Add request origin validation, disable introspection in production, validate queryMap keys against a whitelist, and ensure the GraphQL endpoint is not exposed to unauthorized clients. Consider using a library like
graphql-shieldfor authorization.Changes
data-driven-dependencies/pages/api/graphql.js(modified)