Sensitive Data Masking
Show enough of a sensitive value to recognise it, and no more.
What it adds
Server-side masking of sensitive fields so the full value never leaves the server, with a gated path to reveal it.
What your agent is told to do
6
What your agent is told to do
6-
1
Inventory the sensitive fields first — emails, phone numbers, card numbers, API tokens, national identifiers, bank details — and classify each one.
-
2
Mask at the point the value is serialised on the server. The full value must never be sent to the client and hidden with CSS; that is not masking, it is a suggestion.
-
3
Write per-type rules: cards keep the last four, emails keep the first character and the domain, tokens keep a short prefix. A single generic rule makes some fields useless and others still identifying.
-
4
Apply the same rules everywhere the value can escape: UI, API responses, CSV and PDF exports, application logs, error reports, and internal support tooling.
-
5
Gate any full reveal behind an explicit permission plus recent re-authentication, and record who revealed what and when.
-
6
Do NOT build a client-side show/hide control here — that is owned by Sensitive Field Reveal, which deliberately refuses to toggle server-masked values. This feature is what produces those masked values; the two must not overlap.
Edge cases it handles
7
Edge cases it handles
7- Secrets shown once at creation (API keys) are a separate flow — masked afterwards, never retrievable.
- Search and filtering must work against the real value server-side while still returning masked results, or the feature breaks the app.
- Masking must be consistent across an entire response — one endpoint returning the full value undoes every other.
- Log redaction must cover request bodies, query strings, and exception messages, which are where full values usually leak.
- A reveal must be time-boxed. Do not leave the full value in client memory or in a cached response after the user moves on.
- Some masks still identify: a partial phone number plus a name is often enough. Classify by risk, not by field name.
- Support staff need a different mask level than customers. Make it a permission, not a separate hardcoded view.
Definition of done
8
Definition of done
8- No API response, export, or log contains a full sensitive value without an authorized reveal.
- Each field type has a documented mask rule appropriate to it.
- Masking is applied identically in UI, exports, logs, and support tooling.
- Full reveal requires permission plus recent authentication and is recorded in an audit log.
- Server-side search against real values still functions.
- The client-side toggle remains owned by Sensitive Field Reveal.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Upload Malware Scanning
Upload Malware Scanning
Quarantine uploaded files until they are known safe.
What it does
A quarantine lifecycle for uploads: every new file is unreachable until scanned, with defined handling for scanner failures and infected results.
How it works
- 1 Give every upload an explicit scan state — pending, clean, infected, or error — and default it to pending the moment the bytes land.
- 2 Make pending and infected files unreachable from every access path in the app, including admin views, previews, thumbnails, and any signed URL. A quarantine with one exception is not a quarantine.
- 3 Scan asynchronously and update the state; do not block the upload request on the scanner.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/upload-malware-scanning
Rate Limiting
Rate Limiting
Stop one client from ruining it for everyone.
What it does
Throttling on the endpoints that get abused: auth, search, exports, and public forms.
How it works
- 1 Identify the endpoints worth protecting: sign-in, sign-up, password reset, search, exports, and anything unauthenticated.
- 2 Limit by a stable identifier — user ID where signed in, IP otherwise. Be aware IP is shared behind NAT and proxies.
- 3 Return 429 with a Retry-After header. Do not silently drop the request.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/rate-limiting
Password Generator
Password Generator
Offer a strong password in one click wherever someone sets or changes credentials.
What it does
A generate control on password fields that produces a strong value, shows it, and hands it to the user safely.
How it works
- 1 Add the control to every place a password is set: sign-up, password change, password reset completion, and any admin screen that provisions credentials for someone else.
- 2 Generate the value in the browser using the platform's cryptographic random source. The value must never be produced on the server or sent anywhere.
- 3 Reveal the generated password by default so the user can record it, and offer a regenerate control beside it. A hidden generated password that the user cannot see is a password they will immediately reset.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/password-generator
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.