Passive defence does not generate alarms: it waits. A canary token is its most economical and most narrative form. You do not have to configure anything complex, you do not have to install agents, you do not have to add a component that runs in production. You simply sow something that serves no one and that, therefore, has only one reason to be touched: the curiosity of someone who has nothing legitimate to do with it.
A concept older than networks
The idea was not born in 2010 with cloud platforms. Eighteenth-century cartographers used the same trick: fake data mixed with real data, non-existent cities among authentic names, to unmask whoever copied the maps without a licence. Whoever copied everything, without choosing, carried the invented cities away as well. The copy was identical: make the theft produce a trace.
The same logical step appears in computer security well before "product" canary tokens. In 1986 Cliff Stoll describes the hunt for an intruder who was getting into the Los Alamos systems to steal military programmes, reconstructed by cross-referencing the print job count and telecommunications costs. In 1991 Eugene Spafford recounts intrusions on his Sun workstations that had not triggered any existing alarm, and that had ended with a backdoor installed so as to look intact. These are two stories that lead to the same operational conclusion: detection is not an accessory, it is the product.
Honeytoken: from the network to the object
The term honeypot became established in the 1990s with systems that simulate real services in order to attract and observe. But a honeypot costs: it has to be maintained, it has to be patched, and above all it must never be confused with a real system, or it becomes an attack vector. The honeytoken solves the problem at the root: instead of simulating a service, it simulates a datum. A fake API key, a non-existent AD account, an empty bucket, an email address that nobody knows. No surface to maintain, because there is nothing that works: there is only something that fires.
In the cloud the mechanism is almost free. An S3 bucket with a name that seems
to contain the backups, with a 2 KB object that promises a database dump: the
attacker who finds it tries to download it, the object calls your endpoint, you
receive the IP and the user-agent in real time. The same applies to an AWS
token "use it only for testing" that has no policies but that someone will try
to use anyway, receiving InvalidClientTokenId — and that call, on its own, is
already the alarm.
The blind spot: the canary nobody watches
A canary token that generates traffic nobody monitors is equivalent to a honeypot nobody watches. It is the most common flaw of this technique, and it is the reason why "use and throw away" tokens become an operational nuisance instead of a tool. Three requirements to avoid wasting them:
Collection is integrated into a channel that already exists. Slack, PagerDuty, the SOC email. If the alert arrives in a mailbox nobody opens, the canary is wasted.
The context is written at the moment of creation. A token placed six months ago in a test bucket, when it fires, must be recognisable.
It is rotated and removed. A token forgotten in a public repository becomes noise: scanners flag it and the alert fades on its own.
The value of a canary token is not the trap: it is the certainty that no legitimate access will touch it. It is a signal at almost zero cost, and as a signal it must be treated.
Canarytokens.org
Since 2015 Thinkst has made canarytokens.org available, a free and
self-hostable service that generates tokens of many types — files, URLs,
credentials, email addresses, bitcoin wallets, silently monitored by the
service. The interesting point is that the attacker has no reason to suspect:
the file is called backup_credentials.docx, the email looks like a department
mailbox, the wallet has a balance. They are still credible in 2026, and this is
the difficult part: the credibility of a decoy depends on how similar the
world of the attacker is to the one in which it was created.
What changes with Nuxt (and what does not)
Tokens have nothing to do with the frontend. But a news engine in Nuxt brings
with it a useful novelty: static rendering and link prefetch generate real
requests from real users. Every request towards a non-existent path is a
signal — and a /news/che-non-esiste route visited by an authenticated
user of your VPN is exactly the kind of thing a canary token tries to capture.