CORS Note Attachments note content

[lzinga]

I am using the API to get the content of a note (I have tried both a shared note and non-shared note) and trying to load the content onto a my own HTML page within sveltekit. The HTML and everything works great (albeit more API calls then I would like) but I am running into an issue with the attachments/images.

    // Fix relative image src paths by prepending full base URL
    content = content.replace(
      /src="api\/attachments\//g,
      `src="${baseUrl}share/api/attachments/`
    );

this updated the attachment src to be changed from a relative/local one to a full url, as well as adds the /share/ portion which seems to be the way to access it.

https://subdomain.mydomain.com/share/api/attachments/ieQ2HUVKHuVe/image/image%20(1).png

when I use this URL in a browser manually it works fine and the Trilium share page works fine. However, when I try to place it into an IMG on my own site I get

Request URL: https://subdomain.mydomain.com/share/api/attachments/ieQ2HUVKHuVe/image/image%20(1).png
Request Method: GET
Status Code: 403 Forbidden
Referrer Policy: strict-origin-when-cross-origin

or I get this if I manually change the html in the browser to the address.

GET http://subdomain.mydomain.com/share/api/attachments/ieQ2HUVKHuVe/image/image%20(1).png net::ERR_BLOCKED_BY_RESPONSE.NotSameOrigin 200 (OK)

I have updated the config/environment variables with the CORSALLOWORIGIN but it still doesn't appear to work, I used * for testing purposes. I would not use a wildcard for production.

- TRILIUM_NETWORK_CORSALLOWORIGIN=*

config.ini

# setting the CORS headers for cross-origin requests
corsAllowOrigin='*'
corsAllowMethods='GET,POST,PUT,DELETE,PATCH'
corsAllowHeaders='Content-Type,Authorization'

Is there something I am missing specifically for attachments that will allow me to use the images on the mydomain.com from my Trilium hosted on subdomain.mydomain.com. As note I am using a cloudflare tunnel, however I also tried this using the internal IP:PORT but it had the same behavior.

[dosubot[bot]]

Hi @lzinga! I'm Dosu and I’m helping the Trilium team.

Trilium sets CORS headers globally for all endpoints, including attachments, using the values from your environment variables or config.ini—so your settings should work for images as well as API requests. If you’re still getting CORS errors or 403s, it’s likely due to one of these issues:

• The 403 may be from Trilium’s attachment access checks (e.g., the image isn’t actually shared or accessible to the public, or the share link is expired or restricted).
• Cloudflare Tunnel or another proxy could be stripping or modifying CORS headers, or interfering with request forwarding. This is a common cause of CORS or access issues with Trilium behind proxies or tunnels. Make sure all HTTP methods are forwarded, no paths are rewritten, and headers like Access-Control-Allow-Origin are preserved. See details.
• Chrome and some browsers enforce stricter CORS and cookie rules than others, so always test with multiple browsers.

To debug:

1. Use browser dev tools (Network tab) or curl to inspect the response headers for the image request. Confirm that Access-Control-Allow-Origin is present and matches your expectations.
2. Try the same request directly to your Trilium server (bypassing Cloudflare) and compare the headers and status code.
3. Double-check that the attachment is actually shared and accessible without authentication.

If the CORS headers are present and correct, but you still get a 403, it’s almost certainly an access or proxy issue, not a Trilium CORS config problem.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[lzinga]

Thanks, I will look a little closer, as mentioned I have tried running it against the local address instead of through Cloudflare and the same issue occurs. So, It doesn't appear to be with Cloudflare, at least not in the current state.

[lzinga]

So when I do curl -I http://internal-ip:1337/share/api/attachments/ieQ2HUVKHuVe/image/image%20(1).png my header returns like this

HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,POST,PUT,DELETE,PATCH
Access-Control-Allow-Headers: Content-Type,Authorization
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin
Origin-Agent-Cluster: ?1
Referrer-Policy: no-referrer
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-XSS-Protection: 0
Content-Type: image/jpg
Content-Length: 85012
ETag: W/"14c14-seroT29t0JbXUoSOIoBNeRvNhsU"
Date: Fri, 21 Nov 2025 16:15:02 GMT
Connection: keep-alive
Keep-Alive: timeout=600

which I believe this issue may be happening due to the crossorigin opener/resource policy being same-origin. However I am not seeing how these are being set in the code, if at all. You could probably overwrite these in a nginx settings, but since I am not using one and just using a cloudflare tunnel it appears to make it somewhat more difficult.

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin

[dosubot[bot]]

The Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy headers are set by the Helmet middleware in Trilium’s server code and default to "same-origin" unless explicitly changed. Trilium does not currently expose a config option to modify or disable these headers—they’re not set in config.ini or via environment variables, only in code. To change or remove these headers, you’d need to edit the Helmet options in apps/server/src/app.ts and override them, or use a proxy (like nginx) to strip or rewrite them downstream. See the relevant code and details here.

If you want to patch Trilium directly, you can pass custom options to Helmet in that file, e.g.:

app.use(
  helmet({
    crossOriginOpenerPolicy: { policy: "unsafe-none" },
    crossOriginResourcePolicy: { policy: "cross-origin" },
    // ...other options
  })
);

This would relax those headers for all responses. Otherwise, a reverse proxy is the only workaround without modifying Trilium’s code.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[lzinga]

Perfect, thanks for pointing me to the correct place. I have looked at the helmet.js for Cross-Origin-Resource-Policy and it does seem to default to same-origin if not specified in helmet.

I haven't taken a look at how the config is implemented, but it may be as simple as adding something like this to the apps/server/src/app.ts

if (config["Network"]["corsResourcePolicy"]) {
    res.header("Cross-Origin-Resource-Policy", config["Network"]["corsResourcePolicy"]);
}

and then the user can choose an option from the allowed ResourcePolicy options, same-origin, same-site, or cross-origin

[lzinga]

I have created #7826 to better add this as a feature rather than a discussion.