Keep credentials, raw customer data, step by step exploit details for unfixed flaws, unredacted screenshots and full network maps out of any wiki that many people can read. Store them in tools built for them, and link from the wiki to where they live.
Why a wiki is a risky place
A wiki is built to be easy to write and easy to search. Those same qualities make it a good place for a mistake to spread. Anyone with read access can search for "password" or "token". Page history keeps what you deleted. Exports and backups copy it elsewhere. And a broad audience often includes contractors, new hires and bots.
The keep out list
| Do not store | Why | Put it here instead |
|---|---|---|
| Passwords, API keys, tokens, private keys | Search and history expose them | A secrets manager, with a link in the wiki |
| Raw customer or employee data in examples | Privacy and breach exposure | Synthetic sample data |
| Unfixed vulnerability details naming a system | A roadmap for an attacker | The restricted tracker, with a ticket number in the wiki |
| Full network diagrams and IP lists | Helps reconnaissance | A restricted space for the teams that need it |
| Screenshots with URLs, tokens or names | Hidden data in pixels | Cropped, redacted or recreated images |
| Incident forensics with live indicators | Can tip off an attacker or hold personal data | The incident case file with controlled access |
| Personal notes on individuals | Fairness and privacy issues | HR systems |
Steps to clean up an existing wiki
- Decide the sensitivity levels in plain words, such as open to all staff, restricted to engineering, restricted to security.
- Set the default space to the lowest level and require a conscious choice to go up.
- Search the wiki for terms like password, token, key, secret and private. Review each hit by hand.
- If a real credential appears, treat it as exposed. Rotate it first, then delete the page and its history. Our leaked secret first steps covers the order of operations.
- Add a short "Before you paste" notice to the page template.
- Review who has access to each space every quarter.
Teach by example, safely
Docs often need examples. Use values that are obviously fake, such as the documentation addresses reserved for examples, and a clearly labeled placeholder in place of a key. That way a reader cannot copy a working credential, and a search for secrets does not turn up false alarms. See also how docs should show API keys.
Handling old pages
Archive is not delete. If a page ever held sensitive data, check whether the archive remains visible, and whether version history is exposed. Removing the page from the sidebar while leaving it reachable by link solves nothing.
A Safeguard note
This post is about documentation practice, not a product feature. Safeguard focuses on software supply chain risk: dependency and SBOM scanning, reachability analysis and policy gates. Use a separate tool and a rotation process for credentials.
Quick check
Is a private wiki space safe enough for credentials?
No. Access lists drift and history persists. A secrets manager gives rotation, auditing and tighter access.
Can I describe a vulnerability once it is fixed?
Usually yes, after the fix is deployed everywhere it matters. Remove anything that would still help an attacker against an unpatched system.
Last reviewed: 19 October 2026.
