Most AI writing tools follow the same pattern: open a chat window, paste your message, describe what you want, wait, regenerate if the tone is off. I wanted ichat to skip all of that — select a message, get two ready replies (one casual, one professional), done. But the more interesting problem turned out to be underneath the UI: how do you build something that reads people's private messages and still make it trustworthy?
While designing ichat (by Veyon Solutions), I used the OWASP Top 10 as a mental checklist — not because we're marketing a "security product," but because a tool that touches personal conversations has to earn trust by design, not by policy document.
A01: Broken Access Control → design for "nothing to break into"
The simplest way to avoid access-control bugs is to minimize what there is to control access to. ichat's core flow doesn't persist your message content at all, so there's no long-lived store of other people's data that a bug could ever expose across accounts.
A02: Cryptographic Failures → the best-protected data is data you don't keep
Instead of leaning entirely on encryption-at-rest to protect stored messages, ichat's philosophy is to process a message for the single request it's needed for, then discard it. Less retained data means less that depends on any one cryptographic control holding up forever.
A03: Injection → treat every message as hostile input, always
Since the entire product is "take arbitrary text from a stranger's inbox," every message is treated as untrusted by default — never something to be trusted just because it "looks like" a normal reply.
A04: Insecure Design → the retention policy is the security control
The single biggest architectural decision was choosing not to build a database of user messages in the first place. The one deliberate exception is content a user explicitly reports, which is kept for 90 days purely so it can be reviewed — everything else is designed to not exist after the request completes.
A05: Security Misconfiguration → permissions should match the feature, not the platform default
The Chrome extension only asks for what it needs to add a right-click menu item — not broad access to read every page you visit. If a permission isn't needed for the feature in front of you, it isn't requested.
A09: Security Logging and Monitoring → you can't leak what you didn't log
Because message content isn't stored, it also isn't sitting in application logs waiting to be a future liability — a nice side effect of the "discard by default" philosophy.
Closing thought
None of this makes ichat a security product — it's a small utility for drafting replies. But treating the OWASP Top 10 as a design lens from day one, rather than a checklist bolted on later, is what shaped decisions like never storing messages, keeping the Chrome extension's permissions minimal, and making account deletion instant and self-service from inside the app.
ichat is live on Android and as a Chrome extension, with iOS in development: https://www.veyon.solutions/ichat — built by Veyon Solutions. Feedback on the approach is very welcome.
Top comments (0)