Skip to content

Security: Server-Side Request Forgery (SSRF) in GraphQL Handler#347

Open
tomaioo wants to merge 1 commit into
relayjs:mainfrom
tomaioo:fix/security/server-side-request-forgery-ssrf-in-grap
Open

Security: Server-Side Request Forgery (SSRF) in GraphQL Handler#347
tomaioo wants to merge 1 commit into
relayjs:mainfrom
tomaioo:fix/security/server-side-request-forgery-ssrf-in-grap

Conversation

@tomaioo
Copy link
Copy Markdown

@tomaioo tomaioo commented May 22, 2026

Summary

Security: Server-Side Request Forgery (SSRF) in GraphQL Handler

Problem

Severity: High | File: data-driven-dependencies/pages/api/graphql.js:L1

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.

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-shield for authorization.

Changes

  • data-driven-dependencies/pages/api/graphql.js (modified)

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>
@meta-cla
Copy link
Copy Markdown

meta-cla Bot commented May 22, 2026

Hi @tomaioo!

Thank you for your pull request and welcome to our community.

Action Required

In 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.

Process

In 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 CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant