CORS issue using fetch in frontend JS scripts

[diyoyo]

Hi,
maybe a dumb question, but my fetch(url, options) requests in frontend JS scripts won't work because of CORS issues.
If the GET request does not need headers, then it works fine (with what I tested), but as soon as I need custom headers like : "x-api-user" for instance, then it fails with

...  from origin 'trilium-app://app' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

. This happens whether I add the 3 AccessControlAllow headers in the options.headers or not.

LLMs are all suggesting proxies and not intuitive stuff and yet, the same calls, in python, using jupyterlab in my Brave browser, reach the server successfully.

I'd like to perform this using a Desktop version, so I only played with the Desktop env variables, either at launch using a bat, or in the config.ini (testing it on 1.103.0 and 1.104.0). But should I also change the variables in my server config, in the docker-compose.yml (wouldn't make sense to me, but still asking) ?

[eliandoran]

fetch uses the browser API so it's normal to have CORS issues.
What are you trying to fetch, more specifically? Is it an API inside Trilium or an external service?
For external services the only way to handle it so to use a backend script (or runOnBackend).

[diyoyo]

thanks, it was as simple as that. I didn't really need front end calls, i just needed to test some scripts.

[diyoyo]

@eliandoran I believe I'm getting mad. Has something changed since the day you wrote your answer?

1. My backend script for OpenStreetMap won't work anymore
2. and yet it works if I convert it to front end
3. and the Help (Downloading responses from Google Forms) mentions that a frontend script is needed.

So at the end of the day, frontend or backend ?

Thanks.

[dosubot[bot]]

Not a dumb question at all! The CORS failure is expected behavior — the desktop app's Electron shell enforces standard web security (webSecurity: true) and there's no CORS bypass for external requests [1]. Since your frontend scripts run inside the trilium-app://app origin, any external server that doesn't explicitly whitelist that origin will reject preflight requests. No amount of CORS config on Trilium's side (env vars, config.ini, Docker) will help here, because the restriction is enforced by the remote server, not Trilium.

The fix: use a backend script instead of a frontend script. Backend scripts run in Node.js (server-side), so they're not subject to browser CORS at all. Set your script's MIME type to application/javascript;env=backend and use fetch() directly [2]:

const response = await fetch('https://external-api.com/endpoint', {
    headers: { 'x-api-user': 'your-user' }
});
const data = await response.json();
return data;

If you need to trigger the call from a UI context (e.g. a button in a frontend script), you can delegate to the backend with api.runOnBackend() [3]:

const result = await api.runOnBackend(async (url, apiUser) => {
    const resp = await fetch(url, {
        headers: { 'x-api-user': apiUser }
    });
    return await resp.json();
}, ['https://external-api.com/endpoint', 'your-user']);

This is why your Python/JupyterLab calls work fine — they're also server-side and not subject to browser CORS policies.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[jmrplens]

Two separate things changed since that answer, and the error text tells you which one you are hitting.

If the error mentions api.axios, that is Trilium: it was removed and now throws api.axios was deprecated since 2024 and has been removed following the March 2026 npm supply chain compromise. Please update your script to use the native fetch() API. Porting the call to fetch is the fix there.

If instead you are getting a 403 from Nominatim, that is the frontend versus backend difference you noticed, and it is about the User-Agent. Node's native fetch sends User-Agent: node, which I confirmed against a local echo server. The OSM usage policy asks for a header that identifies the application and says outright that "stock User-Agents as set by http libraries will not do", so node gets refused. Your frontend version works because it runs in Electron and sends a real browser User-Agent.

Setting one fixes it, but there is a trap in how you set it. Measured against the live endpoint, spacing requests out so rate limiting was not a factor:

(no header, Node default "node")          403
"MyGeoApp/1.0"                            200
"MyGeoApp/1.0 (contact info here)"        200
"MyGeoApp/1.0 (https://example.org)"      200
"MyGeoApp/1.0 me@example.org"             403
"MyGeoApp/1.0 (me@example.org)"           403
"me@example.org"                          403

Any User-Agent containing an email address is refused. Parentheses make no difference and a URL is fine, so it is the address itself. That is worth knowing because putting a contact email in the User-Agent is the usual way people follow the "identify your application" instruction, and here it is the one thing that guarantees a block.

So in a backend script:

const res = await fetch(url, { headers: { "User-Agent": "trilium-myscript/1.0 (https://your-site.example)" } });

Worth reading the policy itself before leaning on the public endpoint for anything regular, since it also caps you at one request per second and forbids a few use cases outright: https://operations.osmfoundation.org/policies/nominatim/