Skip to content

ADR-108: GitLab GitLab cookie and JavaScript enforcement

Context

We're seeing increased load on the GitLab server, likely due to rogue LLM bots. We've exhausted normal denial of service mitigation techniques and are forced to deploy more severe workarounds.

Decision

GitLab will now require users to accept and send cookies. This is currently implemented with a "rate limiting" page which issues a cookie through JavaScript or the main login page, which serves as the only exception to the rule.

More elaborate mitigation strategies including proof of work systems like Anubis or more complex systems like Iocaine could be deployed in the future as well.

Consequences

Most users already using GitLab will likely not see a difference.

New visitors, Tor Browser, and users regularly clearing cookies (or not sending cookies at all) will be served the rate limiting page.

Bots, batch jobs and scripts might struggle to access the GitLab server if they do not serve the right cookie. There is an exception in place for a small set of user agents, known GitLab runners, and servers operated by TPA.

For now, the rate limiting page should be transparent to most users with minimal support for JavaScript. Considering that GitLab is almost unusable without JavaScript support, this seems like a minor issue, and there is currently a workaround for JavaScript-less support.

More Information

Much of this work is done under no illusion that it will solve all of our problems.

The main point of those changes is to define more clearly mechanisms by which legitimate use cases (e.g. Gitaly, GitLab runners, our own bots and services) can be exempted from more draconian mitigation strategies that we might deploy later or in an emergency.

See the following issues for more discussions on alternatives and followup work:

Metadata