Please change the API's CORS restrictions

[benmanone]

I think the current CORS settings are far too restrictive, preventing the API from sharing responses with other domains. Please could the Access-Control-Allow-Origin header be modified to allow those of us who want to build web apps using the API to do so? I don't know very much about API development but I think this is a very simple task. I could try to write a PR doing this later today. Thank you

[benmanone]

Strangely, it seems like there is already a permissive Access-Control-Allow-Origin header. However any attempt on my end to make a request is left with a CORS error mentioning that the header has denied the response. This is also mentioned by several people in the original API thread referenced by the wiki.

location ~ \.php$ {
  try_files $uri =404;
  include /etc/nginx/fastcgi_params;
  fastcgi_pass    unix:/var/run/php/tatoeba.sock;
  fastcgi_index   index.php;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  more_set_headers 'Access-Control-Allow-Origin: *';
}

[jiru]

@benmanone Thanks. The code snippet you shared is a good start, however it would allow CORS for every part of the website tatoeba.org, which is rather dangerous. We don’t want that, instead we want to restrict it to the API only. But I am not sure what’s a correct and secure way to restrict the header to API requests only.

By the way, there is a new API under development (which has correct CORS headers) you can use in the mean time. It’s currently documented at https://api.dev.tatoeba.org/ but you can use the same endpoints on https://api.tatoeba.org/ already. There is also an example client.

[orzcode]

Sorry to bump this, but I wanted to see if the CORS policy had been changed/restricted recently.

I built a small web-based language tool using the Tatoeba API last year, and at that time fetch requests worked fine when testing locally, as well as testing through the terminal with node.

Now, though, it only works on the live site, and when I make fetch requests from the terminal or from my local test environment, it fails with CORS errors:

Access to fetch at 'https://api.tatoeba.org/unstable/sentences' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

I'm wondering what changed, if anything?

[orzcode]

I should also note, this fails in node terminal as well.

Failed to fetch Tatoeba for "意見": TypeError: fetch failed at node:internal/deps/undici/undici:13484:13 at process.processTicksAndRejections (node:internal/process/task_queues:105:5) at async tatoebaAPI (file:///home/orz/repos/jmemory/src/tatoebaAPI.js:10:22) at async file:///home/orz/repos/jmemory/src/tatoebaAPI.js:60:13 { [cause]: AggregateError [ETIMEDOUT]: at internalConnectMultiple (node:net:1128:18) at internalConnectMultiple (node:net:1196:5) at Timeout.internalConnectMultipleTimeout (node:net:1720:5) at listOnTimeout (node:internal/timers:596:11) at process.processTimers (node:internal/timers:529:7) { code: 'ETIMEDOUT', [errors]: [ [Error], [Error] ] } }

Using .dev version of the api seems to work in terminal, but still fails with the CORS errors when testing locally in a browser.

[jiru]

@orzcode Although the API was updated recently, the CORS header should not have changed. I just tested with curl and I can see it:

$ curl --silent --show-headers "https://api.tatoeba.org/unstable/sentences?lang=fra&sort=words&owner=gillux"
HTTP/2 200 
server: nginx/1.18.0
date: Tue, 23 Sep 2025 04:29:02 GMT
content-type: application/json
access-control-allow-origin: *

{"data":...}

Now, though, it only works on the live site, and when I make fetch requests from the terminal or from my local test environment, it fails with CORS errors

Maybe the use of localhost is triggering the CORS error?

Using .dev version of the api seems to work in terminal, but still fails with the CORS errors when testing locally in a browser.

There shouldn’t be any header of behavior difference between api.tatoeba.org and api.dev.tatoeba.org at the moment.

[orzcode]

@orzcode Although the API was updated recently, the CORS header should not have changed. I just tested with curl and I can see it:

$ curl --silent --show-headers "https://api.tatoeba.org/unstable/sentences?lang=fra&sort=words&owner=gillux" HTTP/2 200 server: nginx/1.18.0 date: Tue, 23 Sep 2025 04:29:02 GMT content-type: application/json access-control-allow-origin: *

{"data":...}

There shouldn’t be any header of behavior difference between api.tatoeba.org and api.dev.tatoeba.org at the moment.

Yes, I can see it when using Curl too, but attempting to make a fetch call through Node - either through the terminal or in local browser testing, I get the error shown in previous reply. However, changing it to .dev allows it to work.

Now, though, it only works on the live site, and when I make fetch requests from the terminal or from my local test environment, it fails with CORS errors

Maybe the use of localhost is triggering the CORS error?

I did manage to get around this by using Vite's proxy feature, so yes you're probably right. Strange though, as when I was last working on this a few months ago, I was getting neither of these issues and didn't need to use this proxy stuff then.