Cors issue while using search API


I’m using nominatim search query since long time now. And since few days I receive a cors error. On my client side the code hasn’t change since few month, so I wonder what could happens.

I wonder if my client has been blocked ? But I don’t know if there is a specific contact to ask if my site was blocked and if so for which reason ?

Or maybe my request have missing headers ? I try to find solution in docs but for now I hae no solutions.

In any case, here is an example of my request :

GET /search?format=jsonv2&q=rez

User-Agent: Mozilla/5.0 (Windows NT10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: /
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
content-type: application/json
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
Connection: keep-alive

Thanks a lot in advance for those who can help me :slight_smile:

Cors errors are usually printed in the web browser (they are validated by client software). So this looks like your browser must have updated and changed its’ default behavior. Sharing the output from the browser console would be helpful. Is it also possible for you to share the link, where the issue happens so I can investigate it myself?

I suspect you were hitting the server that has been updated to a new rewritten version of the frontend and I think @lonvia has already deployed a fix for CORS issues in the last few hours…

But still I am facing the same issue


Thanks for your responses @NorthCrab and @TomH .

Here is an image of requests :

It seems that is the preflight request that fails like if server do not allows it. At least that is what I understand, but I’m not very good on the understanding of how CORS works.

@TomH, by any chance do you know if the fix is deployed ? I am still facing the issue today.

Looks like you are for some reason trying to send authorization header credentials to search API. This gets blocked by CORS in the browser. Solution: don’t send authorization header for search (I don’t think it needs one). This is most likely some authorization credentials leakage.

1 Like

Can you please share the query?

Have you tried to use the console/terminal instead of a browser for your query?

With curl or wget you can query nominatim like overpass API.

See also and on the help site - there are some additional comments there.

Thank you. It worked for me and Open Street Map has started working.

We have implemented auth interceptor and sending headers to every http request.
Now we are sending headers by excluding nominatim URLs, which worked.

@dancingCycles, there is everything about the request made in my first message. Here is a sample of complet url request made :

It’s ok because it works if I do the request directly in a web browser or postman for instance. I think my issue comes from the headers send by my client web service (service is done with flutter framework).

@NorthCrab, yes it seems to be something like that. But I don’t see any authorization header in the browser debugger terminal (I had share the headers in first post). That’s why I’m troubled by the behaviour here. I thought error means nominatim service expect authorization header that are missing in the request (CORS missing authorization header).

I’m still investigated on what is my problem. Thanks for your help so far.

Problem solved !

My issue comes from the content type header in my headers
content-type: application/json

I don’t know why I put it previously as the content type response is part af url parameters. I guess server was mess strict before on that contentType header and is now rejected.

So, by removing it everything is working good again.

Anyway, thank you everyone for trying to help me :slight_smile:

Beside there is another change, before response was encoded in utf-8, it seems that it’s now encoded in iso. And if I try to set an ‘content-encoding’ header I have the same error as when I put content-type one, meaning a cors error :

Access to XMLHttpRequest at '' from origin 'http://localhost:53365' has been blocked by CORS policy: Request header field content-encoding is not allowed by Access-Control-Allow-Headers in preflight response.

I’ll find a workaround, but by any chance is there a way to precise to the api the charset we want ?
It seems not by reading the documentation here : Search - Nominatim 4.2.3

Shouldn’t you send accept-encoding header instead? Client-based content-encoding is (almost) never supported by upstream servers. Anyway, accept-encoding should already be set automatically by your browser - it’s the one handling the encoding process, not your javascript.

Similar goes to accept vs. content-type when talking about GET requests.

I don’t think that your content-type issues have anything to do with our servers. We indeed don’t send ‘Access-Control-Allow-Headers’ in the OPTIONS response but if that’s what’s tripping your browser, then it has never worked. Nothing has changed with respect to those headers.

The JSON responses are still in UTF-8. If you are referring to the fact that the charset is no longer explicitly specified in the content-type header of the response, then this is not strictly necessary because UTF-8 is the default for JSON according to RFC 7159. Won’t hurt either, so I might just add it back.

Hi !

Sorry for the late response. I don’t really knows why but in any case my charset issue is no longer present, maybe you add back the content type in headers ?

Thank you everyone for the help :slight_smile: