One day, you’re happily coding your web app, making AJAX requests left and right, until suddenly… BAM! Your perfectly fine requests start failing in Microsoft Edge. The console says “403 Forbidden,” but your server logs show the request was fine. What gives?

TL;DR

Edge once blocked same-origin AJAX requests due to a mix of 403 Forbidden responses and something called Cross-Origin Read Blocking (CORB). The browser thought the request might be dangerous, so it threw up a wall. The real problem was how some response headers were set. You could fix it by changing the response type or adding a proper Content-Type header.

What is CORB, Anyway?

First, let’s quickly explain what Cross-Origin Read Blocking (CORB) is. It’s a safety feature browsers use to block dangerous responses from being read by potentially malicious web pages.

Even though your request may be from the same origin, CORB doesn’t always see it that way. When CORB thinks a response might expose user data or secret stuff by mistake, it blocks it.

It usually targets responses like:

• HTML
• XML
• JSON

If those responses are not supposed to be shared — or if their Content-Type is confusing — CORB plays it safe and blocks them.

The Mystery of the 403 on Same-Origin Requests

Many developers found something odd. They were making requests to their own domain (same-origin), but Microsoft Edge was giving them 403 errors. Not cool.

The same requests worked perfectly in Chrome and Firefox. But not in Edge. Why?

Well, it turned out that Edge was applying CORB too aggressively. And instead of silently blocking just the response body (like Chrome), it showed the request as actually failed — with a 403!

This made debugging super confusing, because:

1. Your server logs showed the request as successful
2. The browser console said 403 Forbidden
3. Your app logic thought something was broken when it wasn’t

What Actually Triggered the Block?

There were a few things that caused CORB to kick in. Here are the usual suspects:

• The response had a Content-Type of text/html, even though it was for an API
• The request expected JSON, but the response looked like HTML or XML
• No Content-Type header at all

Edge’s older versions didn’t handle these as gracefully as Chrome. Instead of ignoring them or just removing the body, Edge would return a fake 403 response, as if permission was denied. This confused nearly everyone.

Even worse, because it was a same-origin request, nobody expected CORB to get involved. But it did.

Response Headers to the Rescue

The fix? You got it: headers.

If CORB thinks a response is dangerous, giving it more accurate headers tells the browser what to expect. Like giving a bouncer your ID — it lets you in.

These were the real MVP headers:

• Content-Type: application/json (or the real type your API returns)
• X-Content-Type-Options: nosniff (helps the browser trust the type)

Let’s say your endpoint returns JSON. Don’t let the server respond with text/html or no type at all. That’s a big red flag for CORB, and it may block it.

Also, make sure the handler you use (like a middleware or route) doesn’t accidentally return an HTML error page — especially default 403 or 500 pages. They trigger CORB because, again, they look like HTML where JSON was expected.

How Developers Found Out

This issue was super tricky to track down. Most of the time, CORB problems appear in the browser console with a note saying, “Cross-Origin Read Blocking.” However, in Edge, it just said 403. No hint that CORB was involved.

So developers had to:

1. Compare behavior in other browsers
2. Use dev tools to inspect the network tab
3. Try different Accept and Content-Type configurations
4. Dig through server logs

Eventually, browser experts realized: Edge was applying CORB even for some same-origin requests — especially if the response looked suspicious (like HTML pretending to be JSON).

Sane Defaults Save the Day

As word spread, web developers learned to avoid the “CORB + 403” trap. Here are some helpful rules:

• Always return the correct Content-Type header
• If your API returns JSON, don’t allow it to fallback to 403 HTML errors
• Avoid letting servers guess the type (no magic sniffing)

Many frameworks and servers later patched these behaviors. Developers added error interceptors and middleware to fix the response formatting. Some even forced all AJAX endpoints to use JSON bodies — even for errors — to avoid CORB.

Edge Improves (Eventually)

The good news? Microsoft eventually switched Edge from their old engine (EdgeHTML) to Chromium. That update made Edge behave more like Chrome.

So, newer versions of Edge don’t go crazy over same-origin AJAX responses. They still use CORB, but it’s more subtle. If anything weird happens, it just zeros out the body without screaming “403!” like before.

But it still helps to serve proper headers. That’ll never go out of fashion.

Quick Fix Checklist

Here’s a summary checklist to make sure your AJAX responses play nice with modern browsers:

• Set correct Content-Type — don’t guess
• Add X-Content-Type-Options: nosniff — prevents server magic detection
• Avoid default HTML error pages — especially from middleware or proxies
• Use JSON for both success and error responses on APIs
• Don’t rely on browser quirks — they change all the time

Conclusion

It was a rough patch with Microsoft Edge, CORB, and 403 errors that made web devs scratch their heads in frustration. What looked like forbidden access was really just a sneaky browser protection doing its job — maybe too well.

With better understanding of CORB and response headers, most of this pain can be avoided. Whether you’re using Edge, Chrome, or some browser from the future, the key is simple: tell the browser what to expect, and it will chill out.

Header smart, debug less.