Medusa Penetration Testing

Medusa’s authenticate middleware checks both the actor calling an API route, such as an admin user, a storefront customer or a custom type, and the method used, such as a session, a bearer token or an API key. We test whether every custom route your team added actually has it applied.

Why Medusa findings sit in your custom routes and modules, not the framework

Medusa protects a route with an authenticate middleware that must be wired up explicitly against a route matcher in your project’s middlewares.ts file, checking both the actor type, such as user or customer, and the authentication method, such as session, bearer or api-key, which the admin scope alone supports. Because this is added per route rather than inherited by default, a custom route created without it is not protected at all.

Medusa’s own documentation shows that a route can be built to accept anonymous requests, and that a request carrying an invalid or expired token is not automatically rejected. Its guidance for doing that correctly is to add a second middleware after authenticate that checks for the presence of credentials and returns a 401 if they failed verification. We test every custom route for exactly this gap: one that quietly falls back to an unauthenticated path when the credential presented was wrong rather than absent.

Inside a custom route, the authenticated actor’s ID is available through auth_context.actor_id, and it is the route’s own code that decides what to do with it, typically resolving the record through Medusa’s Query engine before acting on it. We test whether that resolution step actually filters by the requesting actor, or whether a query built without that filter can return or modify a record belonging to someone else.