> If you have a lock with no keys, it is secure, since it can't be opened. As soon as you have one key, the lock is less secure, because now the lock can be opened.

No, not really. Your simplistic example fails to acknowledge that your same-site "lock with no keys" model rendered same-origin-policy completely unusable in projects that fall beyond the scope of a personal hobby project, which left the whole world with no alternative to turn it off. CORS recognizes the absurdity of implicitly assuming that the same origin is the only possible and conceivable safe origin, or even that a site has a single origin.

Therefore, your comparison would actually be between an old lock which was no longer usable and thus forced everyone to go around with no locks, or a lock designed around one of the world's most basic requirements and thus made it possible for the old lock concept to be applicable.

We are not arguing about the usefulness of CORS, of course it is useful. It does not protect you though.

If you have a lock with no keys, it's a non-starter; the door has no purpose. You'd be better off sealing the entrance with bricks.

If you offer a website with an API then CORS is an enhancement in that you're helping protect users from getting owned or hijacked. Alternatively if you can't stomach the risk, you could take down your API, which is about as useful as solving a math equation by multiplying both sides by zero.

"Lock with no keys" isn't particularly uncommon. They exist in the real world as one-way devices.

There's a while saying dedicated to it, "lock them up and throw away the key".

Hahah, alright. I'll grant you that. The lock:CORS metaphor was tenuous at inception, and now it is truly vaporized.

Notice how nobody ever does that with an actual lock. It's a metaphor for never letting them go free.

A lock with no keys can still be opened with a lockpick or just brute force.