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

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⁴. 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³.

• 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.

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. 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. 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⁵.
3. 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⁶. Bonus: your API key stops being visible to anyone who looks at your app in a browser.
4. 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.

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⁷.

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⁸ 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.

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.

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.