Saleor's GraphQL Surface Needs More Than a Title Match

Saleor exposes a GraphQL API and a separate dashboard experience. External measurement has to distinguish a storefront that mentions Saleor from an API endpoint that belongs to the platform. A title search is inexpensive, but it can collect brand pages, documentation mirrors and custom frontends that share very little with the underlying service.

A count-only ZoomEye probe on 2026-11-14 used page 1, page size 1 and sub_type=all. The comparison produced one app match and more than three thousand title matches.

The 3,184 title count is not evidence of 3,184 public GraphQL services. A headless commerce deployment can put the API on api.example.com and a Next.js storefront on www.example.com. The storefront may contain Saleor in its title or metadata while the API has no matching title. Conversely, an agency that builds Saleor stores can rank for the term without hosting one.

The single app match is more product-specific, but a count of one is still a limited observation. It may reflect the exact label accepted by ZoomEye, the current crawl population or the way the response identifies itself. It does not prove that /graphql/ is reachable from the public internet or that authentication is weak.

Saleor's documentation states that GraphQL requests go to the instance's /graphql/ endpoint and that the API is public by default, with anonymous clients and logged-in customers able to call it directly. Public does not mean every operation is allowed. Permissions, authentication plugins and the schema determine what an anonymous caller can do. The measurement should lead to an authorization review, not an assumption of vulnerability.

Useful follow-up separates public storefront queries from privileged mutations. A defender should know which operations are exposed, which require a staff session or app token, and whether OIDC or another authentication layer is enforced. The presence of a GraphQL endpoint also creates a need for query cost limits, introspection policy and monitoring for suspicious operation names.

For asset inventory, retain the endpoint hostname rather than only the storefront hostname. Record the product evidence that links the two. If only a title match exists, tag the record as unconfirmed and keep it out of counts that drive remediation. If the API endpoint is confirmed through ownership records, collect the minimal response metadata needed to identify it.

The gap between 1 and 3,184 is a warning about query semantics. It does not show that one query is universally better. The app field is narrower for this sample, while the title field reaches marketing and storefront pages that may still be useful for discovery. Both have a role when their claims are kept separate.

The practical output is a layered inventory. Start with the small app match set. Expand to title matches only when the review requires discovery. Confirm the API endpoint and authorization behavior with the asset owner. Then describe the result as an observed count and a verification state, not as a count of vulnerable stores.

References

• Saleor API reference
• Saleor authentication and authorization