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 a7e414a (Latest: a7e414a)
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 39a852e (Latest: 39a852e)

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: *

Screencast.From.2025-03-08.22-43-08.webm

[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: *.