Overview
DumpNotes is a Next.js application hosted on Vercel, backed by a Postgres database and object storage on Supabase, with authentication handled by Clerk and payments handled by Paddle. The full list of providers is on the Subprocessors page.
The design principle is simple: a request should not be able to reach another user’s data even if the application code has a bug. Authorisation is enforced at the database layer, where a mistake in a React component cannot bypass it.
Authentication
- Credentials are handled entirely by Clerk. We never receive, transmit or store your password. Hashing, verification, breach detection and session rotation are Clerk’s responsibility.
- Sessions use short-lived tokens that rotate automatically. A stolen token expires quickly.
- Two-factor authentication is supported, including email verification codes when signing in from an unrecognised device. We strongly recommend enabling it.
- Every route except the landing page, sign-in, sign-up, the legal pages and the payment webhook requires an authenticated session, enforced in middleware before any page or API handler runs.
Data isolation
Row Level Security is enabled on every table in our database. Each policy compares the authenticated user’s identity, taken from the verified session token, against the owner recorded on the row. A query for someone else’s notes returns nothing — not an error the client could ignore, but an empty result, because the database refuses to disclose the rows in the first place.
This holds even if the application sends the wrong query, and even if the client-side key is extracted from the browser. That key grants no privileges by itself; authority comes from the session token attached to each request.
Elevated database credentials are used only in server-side code paths that need them — usage metering and payment webhooks — and are never exposed to the browser.
File storage
- Uploaded images live in a private bucket. There is no public URL for them.
- Storage policies scope every object to the uploading user’s folder, with a narrow exception allowing a recipient to read an image that was attached to a message sent to them.
- Files are served through short-lived signed URLs generated per request. A leaked link expires rather than remaining permanently open.
Encryption
- All traffic to and from the app uses TLS. HTTP requests are redirected to HTTPS.
- Data at rest is encrypted by our database, storage and backup providers using their managed encryption.
- We do not offer end-to-end encryption. The service needs to read your notes to index, search and summarise them. See section 8.
Abuse and cost controls
- Sliding-window rate limits on API traffic, keyed by account for signed-in requests and by IP for signed-out ones. Limits are published in the Terms.
- Per-account AI allowances, reserved before a request is made and reconciled against actual consumption afterwards, so a runaway loop cannot silently drain capacity.
- Payment webhooks are verified by cryptographic signature before they are trusted, so a forged request cannot upgrade an account.
- Cross-origin access is restricted to our own origins rather than left open.
Secrets and access
- API keys and service credentials are stored in environment configuration, never committed to source control, and are rotated when a team member’s access ends or a key is suspected exposed.
- Access to production data is restricted to those who need it, used only to investigate a specific problem, and not used to browse user content.
- Dependencies are kept current, and security advisories affecting them are reviewed and patched.
What we do not claim
Security pages tend to imply more than is true. Here is what we are not claiming, as of the date on this page:
- No end-to-end encryption. We can technically read your notes, and so can our database provider’s infrastructure. Search and AI features require it.
- No SOC 2, ISO 27001 or HIPAA certification. Do not store regulated health, payment card or government identity data here.
- No formal penetration test by an external firm has been commissioned to date. Internal security review has been performed.
- No uptime guarantee or service level agreement.
- No paid bug bounty yet — see section 10 for what we do offer.
We would rather tell you this than let a badge imply otherwise. When any of it changes, this section changes with it.
What you can do
- Use a long, unique password you do not use anywhere else.
- Turn on two-factor authentication.
- Sign out on shared devices, and keep your browser and OS updated.
- Be deliberate about what you share — a shared note cannot be un-read once someone has opened it.
- Export a copy of anything you cannot afford to lose.
- Treat any email asking for your password as fraudulent. We will never ask for it.
Reporting a vulnerability
We welcome good-faith security research and we will not pursue legal action against researchers who follow this policy.
How to report
Email admin@dumpnotes.app with the subject line starting SECURITY. Include what you found, how to reproduce it, the impact you believe it has, and anything that helps us confirm it.
What we commit to
- acknowledge within 3 business days;
- give an initial assessment within 10 business days;
- keep you updated while we fix it;
- credit you publicly when it is resolved, if you want the credit.
Rules for research
- Test only against accounts you own. Create a second account if you need two.
- Do not access, modify, delete or exfiltrate other users’ data. If you encounter it accidentally, stop, do not save it, and tell us.
- Do not run denial-of-service, load or spam testing.
- Do not use social engineering, phishing, or physical attacks against us, our staff or our providers.
- Do not test our third-party providers — report those to them directly.
- Give us a reasonable time to fix the issue before disclosing publicly. 90 days is our default, and we will usually be much faster.
Out of scope: missing security headers with no demonstrated impact, rate-limit findings already documented in our Terms, reports generated by a scanner without a working proof-of-concept, and vulnerabilities requiring a compromised device or a person-in-the-middle position.
We do not currently pay bounties. We do respond properly, fix quickly, and credit you.
Incident response
If we detect or are told about a security incident, we contain it, assess what data was involved, fix the cause, and notify affected users and regulators within the deadlines set out in the Privacy Policy. Notifications describe what happened, what data was involved, what we have done, and what you should do.
Contact
Security: admin@dumpnotes.app
[Legal entity name], [Registered address]