allow CORS?

[joernclausen]

Despite #1860, technically I can use Anubis to protect my Wikis.

One of them needs CORS, so I have added the header Access-Control-Allow-Origin: *. When accessing the wiki directly with a browser, this header is present in the reply. When accessing the same site using jQuery (with a modified URL for which I have added an ALLOW rule in the bot policy), this header gets removed and access to the page is denied.

Does Anubis remove this header from the response? Is there a way to pass it through?

[MLuc24]

Anubis isn't stripping it — there's no CORS code in the project at all. Searching the tree for Access-Control or anything CORS-related turns up nothing, and the only response header it ever sets in lib/ is a Refresh in the metarefresh challenge. On the pass-through path it calls ServeHTTPNext and your backend's headers go back untouched.

Which points at what's actually happening: the response you're inspecting isn't your wiki's. When a request doesn't pass, maybeReverseProxy never reaches ServeHTTPNext and Anubis writes its own response instead. The backend is never asked, so of course there's no Access-Control-Allow-Origin on it — that header only exists on responses your wiki produced. The missing header and the denied access aren't two symptoms, they're one: the request is being challenged.

So the question is why your ALLOW rule isn't matching the XHR when it matches the browser hitting the same URL. The usual culprit is the preflight. A cross-origin jQuery call that sets headers or uses a non-simple method makes the browser send an OPTIONS request first, and that's a separate request with its own path through your policy. If the preflight gets challenged, the browser reports it as a CORS failure and never sends the real request — which looks exactly like "the header was removed".

You can match it directly, since method is exposed to CEL alongside path, host, userAgent, headers and query:

- name: allow-wiki-preflight
  action: ALLOW
  expression: method == "OPTIONS" && path.startsWith("/your/wiki/path")

Worth checking your existing rule against the XHR too, not just the browser. If it keys on userAgent, note that jQuery from a page sends the same UA as the browser, so that's fine — but if it keys on headers, an XHR carries an Origin header the navigation didn't, and depending on how the expression is written that can change the outcome.

Quickest way to confirm any of this: Anubis stamps X-Anubis-Rule and X-Anubis-Action on the request, so check what your wiki's access log records for the XHR versus the browser hit. If the XHR never appears in the backend log at all, that settles it — it never got there.

[joernclausen]

I tried what you suggested, so far no success. Maybe a little more context and a few observations:

I am using an HTML page for testing the jQuery access to the wiki (provided by a colleague). You enter the URL, press a button and the request is generated. On a wiki without Anubis but with Access-Control-Allow-Origin: *, this returns the expected result.

When using it with the Anubified wiki, I see this:

The Apache log shows

129.70.xx.yy - - [17/Aug/2026:12:57:01 +0200] "GET /wiki1/index.php/Hauptseite?he=1 HTTP/1.1" 200 4027 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:153.0) Gecko/20100101 Firefox/153.0"

This is the request to Anubis itself. As mentioned in the other thread, usually I should see a second request (because I currently log all access to all vhosts to the same file), either with the same IP address or 127.0.0.1, but otherwise identical. This request is not seen, so indeed the request is not passed to the wiki port.

The response does not contain specific X-Anubis headers, but two cookies techaro.lol-anubis-auth-... and techaro.lol-anubis-cookie-verification-...

Initially I had this rule to allow requests with the parameter ?he=1:

  - name: allow-BIS-requests
    action: ALLOW
    expression:
      all:
        - '"he" in query'
        - '"1" in query'
        - 'query["he"] == "1"'

I added, as you suggested

  - name: allow-preflight
    action: ALLOW
    expression: method == "OPTIONS" && path.startsWith("/wiki1")

BTW: If jQuery would generate OPTIONS requests, shouldn't they be visible in the Apache log?

Is journalctl the way to get to the Anubis log? This is logged during a jQuery request for https://wiki-t3.hrz.uni-bielefeld.de/wiki1/index.php/Hauptseite?he=1:

Aug 17 13:14:19 wiki-t09 anubis[764]: {"time":"2026-08-17T13:14:19.642558924+02:00","level":"INFO","source":{"function":"github.com/TecharoHQ/anubis/lib.(*Server).issueChallenge","file":"github.com/TecharoHQ/anubis/lib/anubis.go","line":191},"msg":"new challenge issued","subsystem":"anubis","host":"wiki-t3.hrz.uni-bielefeld.de","method":"GET","path":"/wiki1/index.php/Hauptseite","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:153.0) Gecko/20100101 Firefox/153.0","accept_language":"de,en-US;q=0.9,en;q=0.8","priority":"u=0","x-forwarded-for":"129.70.xx.yy","x-real-ip":"129.70.xx.yy","challenge":"01a00f6d-f57a-777a-94db-4c5e39331271","weight":10}

I just tried to add a logging rule to my bot policies (as per https://anubis.techaro.lol/docs/admin/policies), but the log file isn't even created. I'm not sure the policy file is read in the first place. Or this fiddeling with systemd to allow writing to a simple file in /tmp isn't working...