Missing CORS headers on `tiles.openaerialmap.org`

[jake-low]

HTTP responses from tiles.openaerialmap.org don't include an Access-Control-Allow-Origin header, so requests for tiles that are initiated via fetch() from JavaScript will be blocked by the browser.

This prevents OpenAerialMap imagery from loading in Rapid, which uses fetch() to retrieve image data and paint it onto an HTML Canvas. The same imagery URLs work in other editors, like iD (which loads imagery via <img src="..."> elements, similar to Leaflet, and browsers don't enforce CORS rules when fetching resources that aren't readable from JavaScript), and JOSM (which isn't a browser and doesn't enforce any CORS rules at all).

Steps to reproduce:

1. Open https://rapideditor.org/edit#map=17.25/8.48699/-13.24068 (centered on Freetown, Sierra Leone)
2. Add a custom imagery source https://tiles.openaerialmap.org/690585b76415e43597ffd7ea/0/690585b76415e43597ffd7eb/{z}/{x}/{y} (corresponding to this mosaic: https://umap.hotosm.org/en/map/freetown-open-drone-imagery_1865)
3. Observe that the background is black; no imagery loads. In the browser devtools you'll see CORS errors for the image tiles.

The same imagery source URL works fine in iD, for the reason described above.

This is an example request sent by Rapid for a tile from this imagery source (using "Copy as cURL" in the devtools to transcribe it into a CLI command):

$ curl 'https://tiles.openaerialmap.org/690585b76415e43597ffd7ea/0/690585b76415e43597ffd7eb/18/121437/124869' \
        -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:150.0) Gecko/20100101 Firefox/150.0' \
        -H 'Accept: image/avif,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5' \
        -H 'Accept-Language: en-US,en;q=0.9' \
        -H 'Accept-Encoding: gzip, deflate, br, zstd' \
        -H 'Origin: https://rapideditor.org' \
        -H 'Connection: keep-alive' \
        -H 'Referer: https://rapideditor.org/' \
        -H 'Sec-Fetch-Dest: image' \
        -H 'Sec-Fetch-Mode: cors' \
        -H 'Sec-Fetch-Site: cross-site' \
        -H 'Priority: u=5, i' \
        -H 'Pragma: no-cache' \
        -H 'Cache-Control: no-cache' -i -L
HTTP/2 302
server: CloudFront
date: Tue, 05 May 2026 20:16:38 GMT
content-length: 0
location: https://titiler.hotosm.org/cog/tiles/WebMercatorQuad/18/121437/124869@1x?url=https://oin-hotosm-temp.s3.us-east-1.amazonaws.com/690585b76415e43597ffd7ea/0/690585b76415e43597ffd7eb.tif
x-cache: FunctionGeneratedResponse from cloudfront
via: 1.1 dc8ab0490cc3f7679073e847e3aabb66.cloudfront.net (CloudFront)
x-amz-cf-pop: SEA900-P1
alt-svc: h3=":443"; ma=86400
x-amz-cf-id: E_vH1w23m_HpbT_WwVIRTAcoXLEVFJx0kVnuXwGa5pFOZIHtXjLLMg==

HTTP/2 200
content-type: image/jpeg
content-length: 25424
date: Tue, 05 May 2026 20:16:43 GMT
apigw-requestid: c6F2EgqooAMEJbQ=
access-control-allow-origin: *
access-control-allow-credentials: true
cache-control: public, max-age=3600
x-cache: Miss from cloudfront
via: 1.1 a68a42ccda456e4f8eddef0ee53f6bae.cloudfront.net (CloudFront)
x-amz-cf-pop: SEA900-P2
x-amz-cf-id: whrHqnzHvuDQUFcyy4SrdWuG88CNjPEahoE1UWhiMnOBI5KklGQA7g==

Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.

Note that access-control-allow-origin: * is included in the final response in the chain, from the titiler.hotosm.org server. But for the browser to approve a CORS request, every response in the chain (including the 302 redirect) needs to include response headers that permit CORS for the request's Origin.

Hopefully this is the right repo to be reporting this issue; if not please let me know. I'm reporting this on behalf of a YouthMappers volunteer and steering committee member who emailed me asking for help understanding why this imagery URL worked in the TeachOSM Tasking Manager when using the embedded iD editor, but not the embedded Rapid editor; I traced the root cause to this CORS issue.

[linear]

TECH-1175

[spwoodcock]

Thank you for the detailed report! This is definitely a problem that should be fixed 😄

I think https://tiles.openaerialmap.org is the old TiTiler instance that will be replaced by the new eoAPI bundled TiTiler for the latest OAM backend.

Would it be an option for you to use either:

1. Use the new STAC-based TiTiler instance on the backend, which has CORS correctly configured. Example tile URL. Use this if you are loading the TMS imagery at a high zoom level.
2. The new global mosaic that renders squares indicating coverage at zooms 1-14 (the styling is rough for now, but it'll improve), then at higher zooms uses the underlying TiTiler instance? (the reason for this split is to avoid using TiTiler at very low zoom levels for a huge amount of COG requests). Please us this one if you plan to load the imagery at very low zoom / global zoom levels.

Let me know how you get on!

[jake-low]

Thanks for the quick reply!

I can confirm that the STAC-based tiler URL you showed does work in Rapid:

https://api.imagery.hotosm.org/raster/collections/openaerialmap/tiles/WebMercatorQuad/{z}/{x}/{y}.png?assets=visual

Which is great! But it does look like that imagery contains multiple OAM sources that have been pre-mosaiced together? This means that in some areas the imagery is different than what can be seen on https://umap.hotosm.org/en/map/freetown-open-drone-imagery_1865 (I'm not familiar enough with this particular project to know if "different" is older or newer / better or worse).

There are also some pieces of the mosaic that aren't true color imagery, which is a bit surprising to me, though perhaps that's known/intended.

In any case, I'll pass this along as a possible workaround. Thanks again for the info.

[spwoodcock]

This is a good example - thanks for testing out & the details! Pretty surprised to also see that pseudocolour image there too!

Definitely needs looking into 😅

Could you possibly use a URL like this to avoid the merging of the image, by selecting a specific COG to render on the new TiTiler instance?

https://api.imagery.hotosm.org/raster/collections/openaerialmap/tiles/WebMercatorQuad/19/242861/249737@1x?url=https://oin-hotosm-temp.s3.us-east-1.amazonaws.com/690585b76415e43597ffd7ea/0/690585b76415e43597ffd7eb.tif&assets=visual

[jake-low]

Hmm, the additional ?url=... query parameter doesn't seem to have any effect when I tested it - I still see the same mosaic of several different OAM sources.

[spwoodcock]

Ah damn, sorry about that!

Another possible solution is to dig through the API docs above and pick out the possible params to filter only what you need.

You can filter by a specific time range in the URL, so could add a range for only the specific day the true colour imagery you needed was uploaded. pgstac-fastapi has a lot of functionality built in! 😄

[spwoodcock]

Or at least I thought it had that option - I'm not 100% now