Security

Nothing here is a certification, an attestation or the output of an audit. No third party stands behind these statements. They describe the system as it is built today.

If a control you need is in the second half rather than the first, we do not have it yet. Ask before you buy rather than after.

Transport

Everything is served over HTTPS. TLS is terminated by our hosting provider, certificates renew automatically, and plain HTTP is redirected. Outbound requests to your site and to third-party APIs use HTTPS wherever the other end supports it.

Identity

Sign-in is handled by Firebase Authentication rather than by us, so we never see or store a password. You can sign in with Google, with GitHub, or with an email address and password.

Where you use a password, our rules are stricter than the platform minimum. Firebase enforces a floor of six characters. We require at least ten, with a letter and either a number or a symbol, and we reject passwords that appear in a list of common choices, that contain long runs or keyboard sequences, or that contain your own name or the local part of your email address. The rule lives in one file, so the checklist you see while typing is the rule the code enforces.

Confirming who you are

An account created with an email address and a password has to confirm that address before its free trial starts. The confirmation link is generated by Firebase and delivered from our own verified sending domain. Signing in with Google or GitHub carries the verification those providers already perform, so it skips the step. Passwords are checked against a longer minimum than the platform floor, a list of common choices, keyboard sequences and repeats, and against your own name and email address.

The record that an address has already taken a free trial is stored as a one way hash rather than as the address itself, so the collection can answer whether an address has been seen without being a readable list of everyone who has ever signed up.

Access control in the database

Every document is scoped to the account that owns it. A signed-in user can read and write their own records and nothing else. The default at the bottom of the rules denies everything not explicitly allowed, so a collection added later is closed until someone opens it deliberately. Several kinds of record are readable by the owner but writable only by the server:

• Subscriptions. A user can write their own profile but not the subscription field on it. Without that split, anyone signed in could grant themselves the top plan from a browser console.
• Usage counters. Readable, so you can see what you have spent. Not writable, because an account that could edit its own meter would have unlimited paid work.
• Billing records. Readable by the customer, written only by the server, so a receipt cannot be forged or edited afterwards. The internal billing event log behind them is closed to the client entirely.
• Integration credentials. Closed to the client in both directions. A connection token is a real credential with no safe partial view, so the interface gets connection status from an API route instead.
• Mail delivery state and the suppression list. Closed in both directions. A client that could delete a suppression could resume mailing an address that complained, and one that could read the list could enumerate other customers' addresses.

Server-side enforcement

Every paid action re-checks the licence on the server. Identity comes from a verified token and the plan from the database through the admin SDK. Neither is taken from the request body, because the caller is exactly the party with an interest in lying about both. The greyed-out buttons in the dashboard are a courtesy; the server-side check is what holds.

Publishing works the same way. Approving a social post in the browser changes what your own dashboard shows. The publish route re-reads the post on the server and refuses anything without a genuine approval.

Secrets

The Firebase service account and every API key are held as environment variables in the hosting platform, not committed to the repository. Client-side code only receives values that are safe to be public.

Scheduled jobs and webhooks

The scheduled job endpoints require a shared secret and refuse anonymous callers. If the secret is not configured they fail closed, rather than running for anyone who finds the URL.

The email delivery webhook is signature-verified, so a forged bounce or complaint cannot suppress a real customer's mail. Events are applied idempotently, so provider retries do not double-count.

Outbound requests

The product fetches URLs you give it, which is the classic route to a server-side request forgery. Every outbound fetch goes through a guard that normalises the URL, resolves it, and refuses private and reserved ranges, loopback, link-local addresses including the cloud metadata range, and their IPv6 equivalents. A connected URL cannot be aimed at internal infrastructure.

Retention

A daily job deletes lead data past its retention window. Under the default policy that is 90 days for an active lead and 30 days for a rejected one. Suppression records are kept indefinitely on purpose, because a record that someone objected has to outlive the data it refers to. Records collected before retention dates existed are backfilled with one rather than left to sit forever.

Each of these is a real gap, not a roadmap item.

• No external security audit or penetration test. No third party has tested this system. The controls above have not been independently verified.
• No ISO 27001 and no SOC 2. We hold no security certification of any kind, and there is no report to request under NDA.
• No bug bounty. We welcome reports, but there is no paid programme and no published reward.
• No formal 24/7 monitoring. There is no security operations centre and no on-call rota. Alerts are reviewed during working hours, so an incident overnight may not be seen until the next day.
• No customer-managed encryption keys. Data is encrypted at rest by our hosting and database providers using keys they manage. You cannot supply or rotate your own.
• No single sign-on and no SCIM. There is no SAML or OIDC integration with your identity provider, and no automated user provisioning or deprovisioning.
• Single-region data residency, not of your choosing. The database lives in one region, fixed when it was created. There is no EU-only or India-only deployment. Where the data sits, and which providers see it, is on the Sub-processors page.

We will update this page as these change. If one of them is a blocker for you, say so before you subscribe.

The likeliest ways an account gets compromised are not things we can fix from here. Use a unique password, or sign in with a provider where you have two-factor authentication enabled. Do not share one account between people. Disconnect integrations you no longer use, because a connected repository or social account is a live credential.

If you find a security problem, please tell us. Write to support@getmadbot.com with enough detail to reproduce it: the endpoint or page, the steps, and what you were able to do that you should not have been. The Acceptable Use Policy covers testing you may not do.

We aim to acknowledge a report within five working days, and will tell you what we did once it is resolved. We are happy to credit you publicly if you would like. There is no reward programme, and we would rather say so than let anyone spend time expecting one.

If personal data we hold is breached, the commitments below apply. They are deadlines, not targets.

• Supervisory authority, 72 hours. Where a breach is notifiable under the GDPR or the UK GDPR, we notify the competent supervisory authority without undue delay and within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people's rights and freedoms.
• CERT-In, 6 hours. For the classes of incident covered by the CERT-In directions of April 2022, we report to CERT-In within six hours of noticing the incident or being told about it.
• Affected customers, without undue delay. Where the breach affects data we process for you, we tell you without undue delay and give you what you need for your own notifications: what happened, the categories and approximate volume of data involved, the likely consequences, and what we did about it.
• Affected individuals. Where the law requires people to be told directly and we are the controller, we tell them. Where you are the controller, that call is yours and we support it.

The Data Processing Addendum sets out these obligations in contract form. Questions about anything on this page go to support@getmadbot.com.