---
title: "Why your app suddenly says something was \"blocked by CORS policy\""
description: "Your browser blocked your page from reading data at another address because that address didn't say your page was allowed. Here's how to fix it."
url: https://www.fomio.ai/blog/why-your-app-suddenly-says-something-was-blocked-by-cors-policy
published: 2026-08-27T18:00:00.301+00:00
updated: 2026-08-27T18:00:00.301+00:00
topic: error-translation
words: 1755
---

# Why your app suddenly says something was "blocked by CORS policy"

Nothing changed in your code overnight — but your app's address or its guest list almost certainly did.

**In short:**

- A browser blocked your page from reading a reply because the other address never said your page was welcome.
- The usual overnight cause is publishing or connecting a domain, which changes the address your app is served from.
- You have not been hacked, and your data is fine — the other server usually answered normally.
- Most fixes are one text box: add your live address, including the www version, to the allowed list.
- Never fix it with a browser extension — your screen works, every user stays broken.

### What is a CORS error?

Your browser refused to let your page read data from a different web address, because that other address didn't say your page was allowed. It's a safety rule built into every browser, not a break-in. The other server usually received the request and answered normally — the browser simply threw the answer away.

You published your app days ago. It worked. You went to bed. This morning a button does nothing, or a list that used to fill with data just sits there empty, and the developer console — the panel with all the small red text — has a line about something being blocked.

Cross-origin resource sharing, the rule about which web addresses may fetch data from which other web addresses, is what's stopping you. Your app lives at one address. Your database, or your login service, or the weather service you call, lives at another. The browser checks the reply for a note saying "requests from this address are welcome." No note, no data.

In almost every write-up by someone in your position, the code is identical to the code that worked yesterday. Something about the address changed, or something about the permission list changed. Those are different problems from a bug, and they are much faster to fix.

## So why did it break overnight when I changed nothing?

Because the two most common causes have nothing to do with you writing anything. Either the address your app is served from changed, or a service you depend on started answering differently.

Publishing is the big one. While you were building, your app was served from a temporary preview address. Then you hooked up your real domain, or hit publish, and the address changed. Your database still has the old address on its guest list. A Supabase community thread describes exactly this from someone who'd just shipped their first version built with Lovable — it worked in development, and stopped the moment it went live[^4]. The fix was project settings, API, "Additional Allowed Origins."

If your app has logins, check the other list too — your site address and the addresses users are sent back to after signing in. Those often need updating at the same moment and cause a separate, similar-looking failure.

Services also change under you. An open discussion on Supabase's GitHub has several people describing the same thing in their own words: it used to work, then it didn't, on projects they hadn't touched — including the permission note going missing from ordinary data requests on a brand new project[^3].

- A feature nobody used until now. You added a page last week that calls something new. The break is new to you, not new to the app.
- You're calling somebody else's service straight from the browser. Most are built to be called from a server, not a web page. Recent integration? Likely culprit.

## What is the red text actually telling me?

The exact wording matters, because each version points somewhere different. Mozilla's developer documentation splits them out, and the differences are worth two minutes of reading before you change any settings.

*What each version of the message means*

| The wording you see | What it means | Where to look first |
| --- | --- | --- |
| No 'Access-Control-Allow-Origin' header is present | The reply came back with no permission note at all | The other service isn't set up to be called from a browser page[^1] |
| ...does not match... | There is a note, but it names a different address | Your allowed-address list — and check there's only one note, naming one address[^2] |
| Response to preflight request doesn't pass access control check | The browser asked a quiet advance question and got no usable answer | Your own function code, if you wrote one[^9] |

That advance question happens automatically whenever a request is even slightly unusual — including most requests that send JSON or carry a login token. It is not something you triggered.

## How do I fix it?

1. **Add your live address to the allowed list** — In Supabase: project settings, API, Additional Allowed Origins. Type it exactly — with https://, no slash on the end. `www.yourapp.com` and `yourapp.com` count as two different addresses, so add both if both work. Then hard-refresh.
2. **If it's a function you wrote, answer the advance question too** — A function has to reply properly to that quiet advance question and include the permission note on every reply it sends — including the ones where something went wrong. The classic miss is adding it to the success path only, so the app works until the first error[^5].
3. **If it's someone else's service, stop calling it from the page** — Put the call in a small function on your own side and have your page call that instead. Your page is then talking to your own address, so the rule never applies[^6]. Bonus: your API key stops being visible to anyone who looks at your app in a browser.
4. **Don't fix it in your browser** — Extensions and command-line flags can turn this check off locally. Your screen will work. Every user stays broken, and now you can't see it. If you installed one to debug, turn it off before deciding anything is fixed.

**Paste this into your AI tool**

```text
My published app at [your exact address] is showing a CORS error in the browser console when it tries to [what the broken feature does]. Here is the exact error text: [paste the whole red line]. It worked before I [published / connected my domain / added this feature].

Find every place this call happens, tell me whether the fix belongs in my Supabase settings or in my own function code, and make the change. Include the permission headers on error responses too, not just successful ones.
```

That last sentence saves a round trip more often than you'd think. The tool cannot see your hosting settings, so give it the address and the exact wording rather than a summary of them.

## Is it me or is the platform having a bad day?

Check the platform before you spend an hour on your own settings. Lovable publishes a running incident history, and it records real outages — including a logged incident where managing custom domains failed outright because Lovable was being rate-limited by one of its own cloud providers[^7].

If your address problem started at the exact moment you tried to attach a domain, rule that out first. That incident is from April 2025 and is illustrative rather than current — the live history page[^8] is where you check what is happening today.

## How do I find out before my users do?

The fix is usually one text box. The bad part is that your app can be broken for eleven hours and look completely fine — the page loads, the design is perfect, and one feature quietly returns nothing. You find out when someone emails you, or worse, when they don't.

Fomio exists for that gap. You paste a link to your app and it watches from the outside, and when something stops working it emails you and says, in plain English, what likely went wrong. It reports one of three things — Working, Having trouble, or Down — and on the paid plans it writes the prompt to paste straight into the tool you built with.

> **Where I'd be straight with you** — An outside watcher checking your public address is very good at catching a site that's down or struggling, and less good at catching a failure that only happens on one screen after a user logs in. This particular error can hide in that blind spot. It often doesn't — a broken data call usually takes visible things with it — but it can.

The free plan watches one app, checks every five minutes, emails you when it breaks, and keeps a week of history, with no card needed. Builder covers three apps, checks every minute, keeps a month of history and adds the fix prompts. Pro goes to fifteen apps and adds a status page your users can look at instead of emailing you. Current prices are at [fomio.ai/pricing](https://fomio.ai/pricing).

## What should I do right now?

Copy the full red line from your console. Then check whether your live address is on the allowed list in your database settings — including the www version.

If it isn't there, add it, and you're probably done in ninety seconds. If it is there, paste the prompt above into your AI tool along with the exact error text, and let it find the call.

## Questions people also ask


### Does this mean my app has been hacked?

No. This is a safety rule working exactly as designed, not a rule being broken. Your browser asked another address for data, that address didn't confirm your page was on its guest list, and the browser threw the reply away rather than hand it over. The other server usually received the request and answered normally. Nothing was exposed and nothing was taken — a permission list simply needs your new address added to it.

### Why does it work on my computer but not for my users?

Two usual reasons. First, you may be testing from a preview address that is still on the allowed list while the live address isn't. Second, you may have installed a browser extension or launched your browser with a flag that turns this check off locally. Both make your screen look healthy while everyone else stays broken. Turn any such extension off, then load your live address in a normal browser window before deciding the problem is solved.

### Do I need to add both www.myapp.com and myapp.com?

Yes, if both actually load your app. As far as this rule is concerned they are two entirely different addresses, and a permission note naming one will not cover the other. Add each one exactly as it appears in the browser bar: the https:// at the front, no trailing slash at the end. Mozilla's guidance is also to make sure there is only one permission note in the reply, and that it names one address.

### Can I just turn this check off?

Not in any way that helps your users. Extensions and command-line flags disable the check inside your own browser only, so your app appears fixed to you and stays broken for everyone else — and now you have no signal that anything is wrong. The real fix is either adding your address to the allowed list, or moving the call to a small function on your own side so your page only ever talks to its own address.


## Sources

[^1]: Reason: CORS header 'Access-Control-Allow-Origin' missing — MDN Web Docs, Mozilla. https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS/Errors/CORSMissingAllowOrigin
[^2]: Reason: CORS header 'Access-Control-Allow-Origin' does not match 'xyz' — MDN Web Docs, Mozilla (2025-07-04). https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS/Errors/CORSAllowOriginNotMatchingOrigin
[^3]: CORS issue · Discussion #29707 — Supabase, GitHub Discussions. https://github.com/orgs/supabase/discussions/29707
[^4]: Hi all. Newbie looking for some (very basic) advice. — Supabase community thread via Answer Overflow (2025-02-14). https://www.answeroverflow.com/m/1329238741381943356
[^5]: Fix CORS Errors in Lovable Apps — RapidDev (2026-03-25). https://www.rapidevelopers.com/lovable-issues/resolving-cors-errors-in-lovable-full-stack-applications
[^6]: Prevent CORS Issues in Lovable — RapidDev (2026-03-25). https://www.rapidevelopers.com/lovable-issues/preventing-cors-issues-when-using-external-apis-in-lovable
[^7]: Custom domain errors — Lovable Status (2025-04-18). https://status.lovable.dev/incidents/01JS3RGZSE4M3JF3ZJ677BMN3S
[^8]: Incident history — Lovable Status. https://status.lovable.dev/history
[^9]: Four Common CORS Errors and How to Fix Them — Descope (2026-03-05). https://www.descope.com/blog/post/cors-errors