CORS headers not injected when specifying root origins and per-resource origins

[afiorillo]

Hi!
I noticed when using the CORS(app, origins=[...], resources={...}) constructor that the origins in the root level are ignore. A simple example application would be

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(
    app,
    origins=["http://localhost:5000"],
    resources={"/a": {"origins": "*"}}
)

@app.route("/a")
def helloWorld():
  return "Hello, cross-origin-world!"

@app.route("/b")
def helloYou():
  return "Hello, localhost!"

app.run(host='localhost', port=5000)

Running this and then using curl, you can see:

• http://localhost:5000/a --> has Access-Control-Allow-Origin: * as expected
• http://localhost:5000/b --> has no Access-Control-Allow-Origin header

If commenting out the resources={...} line then both endpoints have the CORS header, but specific to the localhost origin. Is this intended behavior?

In my particular use case, this came up with an authenticated API (so the origin must not be *) that also contained a swagger.json endpoint that should be public. The idea was that we could make the swagger.json resource served with a * origin, and all other resources served with the listed origins.

[afiorillo]

I had a bit more time to investigate this and found in the documentation:

The settings for CORS are determined in the following order

1. Resource level settings (e.g when passed as a dictionary)
2. Keyword argument settings
3. App level configuration settings (e.g. CORS_*)
4. Default settings

Which led me to a fix for my particular solution, but leaves my original question. My fix initializes the extension with:

CORS(
    app,
    resources={
        "/a": {"origins": "*"},
        # the most general expression at the end
        "/*": {"origins": ["http://localhost:5000"]},
    }
)

Still, the docs would suggest that initializing it in the original way should also work. Should defining a dictionary in resources override the app-level configuration given in other keyword arguments for the extension?

[jbbqqf]

Hi! Triaging older issues — this looks like documented behavior rather than a bug, and the issue can be closed.

Evidence:

• flask_cors/extension.py:20-25 the CORS class docstring explicitly documents the precedence order:

  The settings for CORS are determined in the following order

  1. Resource level settings (e.g when passed as a dictionary)
  2. Keyword argument settings
  3. App level configuration settings (e.g. CORS_*)
  4. Default settings

• flask_cors/extension.py:155-160 the implementation matches: parse_resources flattens the resources dict, then get_cors_options(app, options, opts) overlays per-resource opts on top of kwargs.
• You self-acknowledged this in your follow-up comment: "I had a bit more time to investigate this and found in the documentation: ..."

So routes outside any resources regex don't pick up the top-level origins=... — by design, because if you pass resources=, you're opting into per-resource overrides.

If you'd like the docs phrased more visibly (e.g. an example showing both routes), happy to open a small docs PR. Otherwise would you mind closing this out?

---

Disclosure: I drafted this comment with help from Claude Code while triaging stale issues; the references above were verified manually against main (fa55dcb).