Look twice.Find the gem.

AI agents and MCP servers, each published with its source and what the checks found.

Marketplace

  • Everything
  • AI agents
  • Apps
  • MCP servers
  • Templates
  • What people want
  • What changed this week
  • The verification standard
  • The ooruby Index
  • Servers that publish no source
  • Reliability guides
  • What the catalogue holds
  • Sell here

Our library

  • Everything, in one place
  • Guides
  • Glossary
  • Calculators
  • Checklists and cheat sheets
  • Community

ooruby

  • Home
  • For teams
  • Site status
  • Company projects
  • RSS feed

Verification records what our published tests found on a specific version at a specific date. It is not a warranty, and it does not certify that software is free of defects.

Rubricv1.0
AI agentsAppsMCP serversTemplatesWantedCommunityOur library
Sign inSell
Back to the standard
rubric v1.0

CORS configuration

Cross-origin access is restricted to the origins that need it.

Applies to
apps
Standard references
CWE-942

A finding here is not a failure

Software of any size carries something. A listing that raises findings on this check is still sold, with the findings published and their severity and reachability stated. A badge that only ever said pass would teach people to stop reading it.

Explainer · 2026-09-30

CORS configuration: which websites may read your application's responses

Browsers stop one website reading another's responses unless the second one allows it. A server that allows everyone has switched off the protection its own users relied on.

What this row checks

That cross-origin access is restricted to the origins that need it. Cross-origin resource sharing is how a server tells browsers which other sites may read its responses, through headers such as Access-Control-Allow-Origin.

How it goes wrong

The dangerous configurations are the permissive ones. Allowing every origin opens a server's responses to any page a user happens to visit. Reflecting back whatever origin a request claims, while also allowing credentials, lets any site make requests as the logged-in user and read the answers. Browsers refuse the literal wildcard together with credentials, which is why the reflected origin is the version seen in the wild.

It compounds with missing authentication. The hand run found an MCP server whose optional HTTP mode allowed every origin and required no credentials, so the only thing keeping a web page from driving it was the network it happened to be on.

What restricted looks like

An explicit list of the origins that need access, compared exactly, with credentials allowed only for those. A server with no browser client at all needs no CORS headers, and sending none is the most restrictive setting there is. The test is simple: send a request from an origin that is not on the list and check that the answer does not invite it in.

Sources

  1. MDN: Cross-Origin Resource Sharing (CORS)
  2. CWE-942: Permissive Cross-domain Policy with Untrusted Domains
  3. ooruby: the rubric run by hand on thirty listings

How apps and templates are read for this row

On an app or a template, this row is also answered every night by a reading of the package's published files, never by running it. The rules are app check set v1.0, each with its mapping, an example, the nearest writing it leaves alone, a hand count across every app and template listing, and what a reading of files does not cover.

What this check has found

Nothing in the catalogue has raised a finding on this check. That is a fact about what has been tested so far rather than a guarantee about what is out there, and it is printed because a check that never fires is worth knowing about too.

Other checks

No shipped credentialsDependency advisoriesBehaviour matches the manifestDeclared egressData handling disclosedLicence and provenance

Every listing in the catalogue shows its result on this check, with the findings summarised in public and the full report to whoever bought it. Open the catalogue.