Our Approach to Security at AnotherTodo
A transparent look at how we protect your todo items. Spoiler: it's Neon Postgres with SSL and a prayer.
Security is a core value at AnotherTodo. We take the protection of your data seriously. Your data — specifically, a list of things you need to do — is stored with the same rigour applied to infrastructure handling far more consequential information.
We believe you deserve to know exactly how we protect your grocery list.
Data Storage and Encryption
AnotherTodo runs on Neon Postgres, a serverless PostgreSQL database with encryption at rest. This means your todo items — “buy milk,” “call dentist,” “finally respond to that email from March” — are encrypted when sitting on disk.
In transit, all data moves over TLS. The connection between your browser and our servers is encrypted. The connection between our servers and the database is encrypted. No one is intercepting your task list in transit. We have made sure of this.
Your todos live in a single table. The schema is not complicated. There is an id, some text, a boolean for completion status, a timestamp, and a reference to your user account. This table is protected by the full weight of Neon’s infrastructure — multi-region redundancy, continuous backups, point-in-time recovery.
For a todo list.
Authentication
Access to your account is controlled via session-based authentication. When you sign in, we create a server-side session and issue you a cookie. The cookie references the session. The session lives in the database. When you make a request, we look up the session, verify it’s valid, verify it belongs to you, and then allow or deny the request accordingly.
This is a well-established authentication pattern. It is not novel. It does not need to be novel. Your todo list does not require a zero-trust architecture — it requires that other people cannot see your todos, and session-based auth accomplishes this.
Passwords are hashed. We use bcrypt with an appropriate cost factor. We do not store plaintext passwords. We do not know your password. If you forget it, we reset it — we cannot retrieve it, because it does not exist in retrievable form anywhere in our system.
This is the minimum acceptable standard for a consumer application. We meet it.
MCP Token Security
AnotherTodo is an MCP server. Each user gets a unique MCP token — a long, random string that looks like tmcp_ followed by a lot of characters. This token authenticates your requests from Claude.
Treat this token like a password. Do not share it. Do not commit it to a public repository. Do not paste it into a form that asks for it outside of a Claude integration. If you believe your token has been compromised, you can regenerate it from your dashboard. The old token immediately stops working.
Your MCP token has access to your todo list and nothing else. It cannot access billing information. It cannot delete your account. It can list, add, update, delete, and toggle todos. The blast radius of a compromised MCP token is: someone can mess with your todos.
We have considered the threat model. It is not severe.
Payment Security
We do not handle your payment information. We do not store card numbers, CVVs, billing addresses, or any other financial data. This is not us being modest — we genuinely don’t have it.
Stripe handles all payments. Stripe is a payments infrastructure company whose entire business model depends on being trustworthy with financial data. They have SOC 2 Type II certification, PCI DSS Level 1 compliance, and a security team larger than our entire operation.
When you enter your card details on our checkout page, you are entering them into a Stripe-hosted iframe. The information goes directly to Stripe. We receive a customer ID and a subscription status. That is the full extent of our financial data holdings.
If someone compromises AnotherTodo entirely, they get your todos and your email address. They do not get your credit card number. This was a deliberate architectural decision and we are proud of it.
Rate Limiting
Our API enforces rate limits. The MCP endpoint accepts 60 requests per minute per token. The web API has equivalent limits.
This prevents abuse. It also means that if you are somehow hitting rate limits while managing a personal todo list, something has gone wrong that is not a security issue but may be a mental health one.
Rate limiting is applied at the infrastructure level. Requests that exceed the limit receive a 429 response. The limit resets on a rolling window. This is standard practice. We document it because transparency is important, and also because we are running out of security features to describe.
Data Deletion
If you delete your account, your data is deleted. Not archived. Not anonymized and retained for analytics. Deleted.
Your todos are deleted. Your user record is deleted. Your session data is deleted. Your MCP tokens are invalidated and deleted. Your Stripe subscription is cancelled.
We do not have a compelling business reason to retain your data after you leave. You had a list of things to do. You no longer want us to store it. We don’t keep it.
This process is initiated from your account settings and completes within 24 hours — the window exists to allow for Stripe webhook processing and background job completion. We are not using that window to make a copy.
Responsible Disclosure
If you discover a security vulnerability in AnotherTodo, we would like to know about it. You can email us. We will investigate. We will fix it. We will not threaten you with legal action for finding it, because we are not that kind of company and also because the data at risk is someone’s grocery list.
We do not have a bug bounty program. We have gratitude and the knowledge that you have made the world’s most modestly-scoped productivity application marginally more secure.
A Note on Proportionality
We want to be transparent about something.
The security posture described in this document is appropriate and real. The data it protects is, objectively, low-stakes. We are aware of this tension.
Your todo list is encrypted at rest not because an adversary is specifically targeting your note to buy more coffee filters, but because encryption at rest is a default feature of our database provider and it would be odd to opt out. Your sessions are secured not because your account represents a high-value target, but because unsecured sessions would be unprofessional.
We built this with reasonable security practices because reasonable security practices are the right way to build software. The data being protected happens to be a list of tasks. We are at peace with this.
If you have security concerns about your todo list, we recommend therapy. If you have security concerns about our todo list — the application, the infrastructure, the data handling — email us and we’ll take it seriously.