Why Chrome blocks ajax locally?

  • Could not find dup, so let me know if there is one

    I am trying to create static one page website (to host it on neocities). I use jquery's load() function for that. It works fine in Firefox (and Edge) but not in Chrome.

    Here is index.html:

    <!DOCTYPE html>
        <meta charset="UTF-8">
        <div id="partial-page-load-section"></div>
        <script src="jquery-1.12.4.min.js"></script>

    and here is partial_page.html:

    <h1>This is partial page</h1>

    Error message by Chrome:

    Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https.

    Screenshot (Chrome one the left, Firefox on the right):

    enter image description here


    1. Does Chrome solve some kind of vulnerability by not allowing me to do what I am trying to do which would not have been possible to solve in any other way other then completely preventing me from doing what I am trying to do?
    2. If somebody were to try to exploit vulnerability which Chrome is trying to fix by blocking my request, how would they go about it?
    3. Does that mean that Firefox (and Edge) are (more) vulnerable to XSS or CORS (or something else)?

    What is the URI scheme of the page you're looking at? `file` or `http`?

    @AndrolGenhald `file`

    Note that Firefox is also now blocking Ajax call, like Chrome, when the file is played locally, unfortunately. To test files locally - which contain Ajax call (loading xml for instance or accessing svg content inside ) we can still use IE.

    @Serge Thanks for heads up. This babysitting is unfortunate, indeed.

  • Xenos

    Xenos Correct answer

    3 years ago

    CORS is layered over HTTP so it makes somehow no sense to deal with CORS besides http https chrome and chrome-extension since the last 3 probably (I lack doc here) relies over the same rules as HTTP.

    Any other protocol behavior for CORS is undefined for now. So Chrome blocks it.

    To answer each question individually:

    1) No, they just consider that since the CORS is not defined for other protocol, the safest is to crash with an error saying "not implemented"

    2) Since 1) answer is No, this question is not applicable. But if Chrome let the request go, then it's up to the unknown-protocol to properly handle CORS, which will probably not be done right

    3) The difference between Firefox and Chrome is that Firefox first check if origins of the requester document and the requested resource are the same (and if so, it let it through, otherwise, it follow CORS process) while Chrome always follow the CORS process before checking the origin matching.

    -I don't know which behavior follow best the Fetch specification- It seems that both are ok since part of the spec says

    "file" "ftp"

    For now, unfortunate as it is, file and ftp URLs are left as an exercise for the reader.

    When in doubt, return a network error.

    The only harm I could see is that Firefox would let a script display sensitive information from file:/// on your screen, that a shoulder spyer could grab. It's not related to CORS then.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM

Tags used