Security

MastroSDR holds two things worth protecting: your prospect lists and the provider keys you connect. Here is specifically how each is handled.

Workspace isolation

Every database query is scoped by workspace, taken from your session or API key and never from a request parameter. There is no endpoint that accepts a workspace id from the caller. This is covered by automated tests that assert one workspace cannot read, edit or delete another's records.

Your provider keys

• Encrypted at rest with AES-256-GCM, which is authenticated, so a tampered value fails to decrypt rather than silently returning something wrong.
• Never displayed again after you save them. The interface shows only the last four characters.
• Never written to logs, audit records or error messages.
• Removable at any time from Settings.

API keys

• Stored only as a SHA-256 hash, so a database leak yields no usable key.
• Shown once at creation and never recoverable.
• Scoped: a key gets only the permissions you tick. Sending is a separate permission from drafting.
• Revocable instantly, and rate limited per key.

Accounts and sessions

• Passwords are hashed, with a 12 character minimum.
• Sign-in and sign-up are rate limited to blunt credential stuffing, with counters held in the database so limits hold across servers.
• Sessions are httpOnly, secure in production, and same-site.
• Roles are enforced on the server for every route, not merely hidden in the interface.

Payments

Card details go straight to Stripe and never touch our servers. Subscription state is written only from Stripe webhooks whose signature we verify; returning from a checkout page grants nothing on its own.

Sending safeguards

• The do-not-contact list is checked immediately before every send, including sends triggered by an API key or a scheduled follow-up.
• Unsubscribes, hard bounces and spam complaints are added to it automatically and permanently. If an address was already on the list by hand, a genuine opt-out upgrades that entry, so it can no longer be removed.
• Matching ignores +tags, so unsubscribing as you+news@example.com also stops mail to you@example.com.
• Delivery webhooks are signature-verified with a replay window.
• Sending requires a from-address on a domain you have verified.

Audit trail

Sign-ins, invitations, role changes, settings changes, integration connections, key creation, every edit to a draft and every send are written to an append-only log. A send records the recipient, the subject and the time on the log entry itself, so the record survives the prospect later being deleted. Actions taken in the browser also record the IP address and user agent; a send made by the scheduler has no request behind it, so those are empty. The application never updates them. They are deleted only by the twelve-month retention limit stated in the privacy policy, or when the whole workspace is closed and everything belonging to it goes with it.

Reporting a vulnerability

Email security@mastrosdr.com with steps to reproduce. We will acknowledge within three business days. Please give us reasonable time to fix an issue before disclosing it, and do not access data that is not yours while testing.

Honest scope. This page describes controls implemented in the product. It is not a claim of SOC 2, ISO 27001 or any other certification. If you need a formal attestation, ask, and we will tell you where we actually stand.