DELETE endpoints do not include ‘Access-Control-Allow-Origin’ in the header which causes web browsers to report a CORS error

[mwoolweaver]

Versions

Core Version is v6.0.4-1-ga7e414ac (Latest: null) Branch is development Hash is a7e414ac (Latest: a7e414ac) Web Version is v6.0.1-10-gec8beaf5 (Latest: null) Branch is development Hash is ec8beaf5 (Latest: ec8beaf5) FTL Version is vDev-39a852e (Latest: null) Branch is development Hash is 39a852ed (Latest: 39a852ed)

Platform

• OS and version: Ubuntu 24.04.2

• Platform: Raspberry Pi 4

Expected behavior

Access-Control-Allow-Origin: * to be in the header like it is with other endpoints

Actual behavior / bug

Access-Control-Allow-Origin: * is missing and seems to cause Firefox and Chrome to report a CORS error

Steps to reproduce

Steps to reproduce the behavior:

https://gist.github.com/mwoolweaver/f5fe7a58f38cfe68e05b7b5e491e65fc

simple website to allow quickly disabling pihole via bookmark

1. download the file locally (not on Pi-hole)

2. Open in firefox or chrome and fill in the boxes with relevant info and open the inspector before clicking submit

3. click submit and watch the DELETE request show a CORS error

4. now host that same file on the Pi-hole device, repeat steps 2 & 3

5. now you will see the 204 response that's expected without the CORS error

Debug Token

• URL: https://tricorder.pi-hole.net/u4r5FwQr/

Screenshots

Additional context

Add any other context about the problem here.

[mwoolweaver]

i know that additional headers can be included but i don't understand what causes the DELETE to fail when not hosted on Pi-hole device and all the other requests are successful

[mwoolweaver]

Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: *

these are included in the response of every other endpoint that's not a DELETE endpoint from what i can see.

[DL6ER]

Access-Control-Allow-Origin: * to be in the header like it is with other endpoints

Is it?

From another machine:

$ curl -Ik https://pi.hole/admin/login
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate, private, max-age=0
Expires: 0
Pragma: no-cache
Content-Security-Policy: default-src 'self' 'unsafe-inline';
X-Frame-Options: DENY
X-XSS-Protection: 0
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Content-Type: text/html; charset=utf-8
Date: Sun, 23 Feb 2025 18:47:38 GMT
Connection: close

On the Pi-hole itself:

$ curl -Ik https://localhost/admin/login
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate, private, max-age=0
Expires: 0
Pragma: no-cache
Content-Security-Policy: default-src 'self' 'unsafe-inline';
X-Frame-Options: DENY
X-XSS-Protection: 0
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Content-Type: text/html; charset=utf-8
Date: Sun, 23 Feb 2025 18:48:32 GMT
Connection: close

I don't see Access-Control-Allow-Origin or any of its friends here.

[mwoolweaver]

I wonder where Firefox and Chrome are getting them from?

this is Firefox

this is Chrome

[DL6ER]

I am undecided concerning the Access-Control-Allow-Origin (and friends) headers. How should they look like on Pi-hole? Should we set them?

[yubiuser]

I would be cautious with headers like Access-Control-Allow-Origin: *. I don't understand why we would need any CORS headers - everything is hosted at locally at pi.hole (or webserver.domain).

[mwoolweaver]

How should they look like on Pi-hole?

this is what i get from the API

curl command that i tried, was copied directly from /api/docs added -i to get response headers

mike@blockbuster:~$ curl -i -X POST "https://pi-hole.home.woolweaver.bid:443/api/auth"  -H 'accept: application/json' -H 'content-type: application/json'  -d '{"password":"passw0rd1234"}' 
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate, private, max-age=0
Expires: 0
Pragma: no-cache
Content-Security-Policy: default-src 'self' 'unsafe-inline';
X-Frame-Options: DENY
X-XSS-Protection: 0
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Set-Cookie: sid=22qWMcS1tG/Ut4yJESLUhQ=; SameSite=Strict; Path=/; Max-Age=1800; HttpOnly
Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: *
Content-Type: application/json; charset=utf-8
Content-Length: 178
Date: Sun, 09 Mar 2025 03:32:08 GMT
Connection: keep-alive

{"session":{"valid":true,"totp":true,"sid":"22qWMcS1tG/Ut4yJESLUhQ=","csrf":"UJMLMiYbIJgORUW5H0hbkw=","validity":1800,"message":"app-password correct"},"took":0.7195274829864502}

same request via javascript in firefox

Should we set them?

If they aren't set currently, where are they coming from?

my webserver.headers is set to the default options

Content-Security-Policy: default-src 'self' 'unsafe-inline';
X-Frame-Options: DENY
X-XSS-Protection: 0
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

[mwoolweaver]

a screen recording of Pi-hole Web UI in Firefox with every api endpoint response header contains the same

Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: *

https://github.com/user-attachments/assets/b9bb47d8-dbaf-49d5-978d-7e96c9bb721d

[mwoolweaver]

this can also be seen when using https://pi.hole/api/docs/#get-/auth

click the try button and then view what is shown for response headers, you will see the following IF logged in

access-control-allow-headers: *
access-control-allow-methods: *
cache-control: no-cache, no-store, must-revalidate, private, max-age=0
connection: keep-alive
content-length: 176
content-security-policy: default-src 'self' 'unsafe-inline';
content-type: application/json; charset=utf-8
date: Sun, 09 Mar 2025 05:30:33 GMT
expires: 0
pragma: no-cache
referrer-policy: strict-origin-when-cross-origin
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 0

maybe this is something that is an API specific issue since it seems the inclusion of Access-Control-Allow-Origin (and friends) headers is not intended

I would be cautious with headers like Access-Control-Allow-Origin: *.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.

[mwoolweaver]

Never stale

[jonbranan]

I have been seeing the same thing. I am trying to create a gui to deploy new selfhosted apps and while the request may go through, it blocks my application's error handling(Ignore the 429, I am rate limited):

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.

[mwoolweaver]

Never stale

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.

[mwoolweaver]

Never stale

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.

[gentielezaj]

like all of you im trying the same thing I do not get Allow headers in PUT and in DELETE methods any fix?

[mwoolweaver]

any fix?

no solution has provided yet.

[DL6ER]

Sorry for the loooong delay in replying, I am trying my best these days to catch up on things.

If they aren't set currently, where are they coming from?

I guess the browsers are injected them due for some obscure reasons. Your curl didn't show them, or am I mistaken? From my point of view, we are still (about, not exactly) where we started: Should we add them by default and - if so - what should be the content. Note that I am not very (as in: almost absolutely not) sure what possible adverse consequences could be. I do not what to make things worse in other regions we might not be thinking about right now.

If someone could dig out some trustworthy description of what to do and why, I'd be more than happy to implement this change!