nullcipher

Bearer tokens and Basic credentials (Authorization: Bearer …, Authorization: Basic …)

The token after Bearer, or the base64 user:password after Basic, in an Authorization header or a curl -H argument. The header name and the scheme stay. Below: the exact rule, a live check, why it matters, and what to do if one already leaked.

Live check: Bearer token or Basic credential

What an AI chat would receive after masking

curl -H "Authorization: Bearer [BEARER_1]" api.example.com/v1/me
Authorization: Basic [BEARER_2]

2 × Bearer token or Basic credential found and masked.

How nullcipher recognises it

The token after the word Bearer (at least 12 token characters, including a digit, so "Bearer authentication" in prose is left alone), and the base64 value after Basic when it decodes to user:password — in an Authorization header, a curl -H argument or a log line. The words Authorization, Bearer and Basic stay; only the credential is masked.

This is the rule text of the “Bearer token or Basic credential” detector in the masking engine, copied from the engine when this page was built. Detectors run in a fixed order and, where two overlap, the earlier one wins.

Example (fake)

curl -H "Authorization: Bearer EXAMPLE0token1not2real3" api.example.com/v1/me
Authorization: Basic ZXhhbXBsZTpub3QtcmVhbA==

nullcipher replaces it with [BEARER_1] and [BEARER_2]. The Bearer token spells EXAMPLE…not…real, and the Basic value decodes to example:not-real. After masking the AI still sees Authorization: Bearer and Authorization: Basic, so it can tell you whether the scheme, the header name or the URL is wrong.

Why it matters in an AI chat

RFC 6750 defines a bearer token as one that any party in possession of it can use, in any way any other holder can. There is no second check: a token copied out of a chat works for whoever copies it, from anywhere, until it expires or is revoked.

Basic is not a token at all. The value after Basic is the account's user:password in base64, which anyone can decode in one step (dXNlcjpwYXNz is user:pass). RFC 7617 calls the cleartext transmission of the password the most serious flaw of Basic authentication.

These headers arrive in chats inside curl -v output, a browser's Copy as cURL, Postman exports and API logs, usually with the question "why does this return 401?". The answer depends on the header name, the scheme and the URL, which stay visible; it never depends on the token's value.

If it already leaked

  1. Check how long it lives. RFC 6750 says a bearer token's lifetime MUST be limited and recommends one hour or less, so a short-lived access token may already be dead. Personal access tokens and API tokens often last months or never expire; those need revoking now. [1]
  2. Revoke it where it was issued: delete the personal access token or API token in that service's settings. If it came from an OAuth server that offers RFC 7009 token revocation, send it to the revocation endpoint; revoking a refresh token there should also invalidate the access tokens issued from the same grant. [2]
  3. For a Basic credential, change that account's password: the header is the password, only base64-encoded. If the same password is used anywhere else, change it there too; RFC 7617 warns that people reuse one password across sites. [3]
  4. If the token is a JWT (it starts eyJ and has two dots), nullcipher masks it as a JSON Web Token instead, and that page explains how its exp claim tells you when it stops working.

Sources

  1. RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage (section 1.2 Terminology, section 5.3 Summary of Recommendations) — checked 2026-09-23.
  2. RFC 7009: OAuth 2.0 Token Revocation, section 2.1 Revocation Request — checked 2026-09-23.
  3. RFC 7617: The 'Basic' HTTP Authentication Scheme, section 4 Security Considerations — checked 2026-09-23.

Open the full masking tool to mask a whole log, .env file or e-mail — every type at once — and restore the values in the AI's answer. Or see all 30 secret types and how to delete a chat you already sent.