Security

• Data is encrypted in transit over TLS, and at rest by our database provider.
• Passwords and PINs are stored as salted scrypt hashes. Nobody at Dialspire can read them, and neither can anyone who obtains the database.
• Every credential you enter — carrier keys, mailbox app passwords, CRM tokens — is encrypted with AES-256-GCM under a key held outside the database.
• Call recording is off until you switch it on, and you control how long it is kept.
• Every supplier that can reach your data is named on our sub-processors page.

A calling floor often means a shared workstation, so Dialspire has two levels of credential rather than one.

• A password is the account’s master key: signing in on a new device, and resetting the account.
• A four-to-six digit PIN covers the fast path only — unlocking your own idle session, or handing a shared browser to a teammate — so nobody types a full password twenty times a shift, and nobody leaves a session open because typing it is a nuisance.

Both are stored as salted scrypt hashes and verified in constant time. Neither is ever stored in a form that can be turned back into what you typed, and admins never see or set a teammate’s credentials — an invited rep chooses their own from a single-use link that expires.

Brute force

Failed attempts are counted in the database rather than in memory, so the limit survives the serverless environment the app runs in. Too many failures locks the account for a period. The password screen and the PIN screen share one counter, so guesses at an unlocked machine and guesses at the login form add up instead of giving an attacker two separate budgets — and the PIN gate carries a second, device-scoped counter, so someone at a locked shared workstation cannot cycle through the teammate picker for a fresh five guesses per name.

Account enumeration

Signing in with an address that does not exist takes the same time as signing in with one that does, because the server hashes against a decoy when there is no stored credential. Without that, response timing turns the login form into a way of finding out who has an account.

A session cookie is split in two: the browser holds an identifier and a secret, and only a hash of the secret half is stored. Somebody who obtains the session table cannot replay a session out of it.

• The cookie is httpOnly, so page scripts cannot read it; SameSite=Lax, so a browser will not attach it to a cross-site request; and Secure in production.
• Every device you have signed in from is listed in your account settings with its browser and IP address, and can be revoked individually.
• Changing your password signs out every other device. Changing a password is how someone responds to one they think is known, and leaving the other devices signed in would defeat that.
• Sessions expire after 30 days.

Nothing a customer types as a secret is stored in plain text. If the encryption key is not configured, storing a credential fails with a clear message rather than quietly saving it in the clear.

Every workspace is a separate organisation in the database, and every query is scoped to the caller’s organisation on the server. Access checks are enforced in the API, not hidden in the interface — a rep who types a manager-only URL gets a refusal, not a page that happens not to render a button.

Anything an API returns reaches the browser, so procedures that read a record holding credentials return an explicit subset of its fields. That rule is enforced mechanically: a type-level test fails the build if a password hash, a PIN hash, a stored token or a billing identifier is ever added back to a response.

Response headers

Every response carries HSTS, nosniff, X-Frame-Options: SAMEORIGIN, a restrictive Permissions-Policy, and Referrer-Policy: strict-origin-when-cross-origin — the last one because password-reset, unsubscribe and checkout links carry a secret in the query string, which would otherwise leak into a third party’s referrer log.

Cross-site request forgery

There are two locks. The session cookie is SameSite=Lax, and every mutation additionally checks the request’s Origin — because Lax is a browser-side policy that treats sibling subdomains as same-site.

Webhooks

Every inbound webhook verifies its signature before it reads anything from the database. Some of these routes answer with a lead’s telephone number, so a call identifier on its own is never treated as authorisation. Where a provider fetches a URL from us instead of posting to us, that URL is itself signed.

Outbound requests

Where the product fetches a URL a customer supplied, address validation is bound to the connection’s own DNS lookup, redirects are not followed, and the response is capped — so a hostname cannot resolve to something harmless during the check and to an internal address during the connection.

Abuse limits

Imports are capped by rows, columns and cell size and written in batches, and the public enquiry form is rate limited, so a single request cannot be turned into an unbounded write.

• Recording is off by default in every new workspace, because the consent rules for recording a call vary by jurisdiction. An admin has to switch it on deliberately.
• Call audio is fetched from your carrier using your carrier’s own credentials and forwarded to the transcription provider as bytes. We never hand a third party a carrier media URL, because in practice such a URL is a bearer credential anyone holding it could replay.
• A call placed through a dialler we merely launch is never transcribed, because we never had the audio — a transcript attached to one would be fabricated.
• What the AI proposed is stored separately from what the rep chose, so a machine guess is never exported to your CRM labelled as a human decision.

Admins can set a retention window for recordings and for transcripts. A scheduled sweep runs nightly and clears anything past it — and clears the AI summary alongside the transcript it came from, since keeping the summary would defeat the deletion. A single call’s media can also be purged on request.

Deleting a whole workspace is a separate, deliberate act: an admin confirms by typing the workspace name, which starts a 30-day window they can still call off, and only then does a nightly job delete the workspace and everything belonging to it. Cancelling a subscription does not trigger it — a lapsed card must never be able to destroy a customer’s data.

Dialspire runs on managed infrastructure rather than servers we rack ourselves. Every supplier that can reach personal data is named, with what it does and what it sees, on our sub-processors page, and we give 30 days’ notice before adding one.

Card details never reach us: payment is taken on Stripe’s own hosted page, and we store only Stripe’s identifiers for your customer and subscription.

A security page that lists only strengths is not much use for due diligence. As things stand:

• No SOC 2 or ISO 27001. We hold no third-party security certification. [UPDATE IF AND WHEN A CERTIFICATION IS OBTAINED]
• No independent penetration test yet. [UPDATE WITH DATE AND SCOPE ONCE ONE IS COMMISSIONED]
• No SSO or SAML. Accounts are password plus PIN. There is no directory integration.
• No full Content-Security-Policy. The parts that cannot break a call are in place; the script and connection directives are not, because the browser softphone opens carrier connections at runtime and a policy that missed one would kill dialling silently. Adding them means deriving the origins against a live carrier and shipping in report-only mode first.
• No published uptime commitment. See the terms of service.

If you have found a security problem, please tell us before you tell anyone else. Write to [SECURITY CONTACT EMAIL] with enough detail to reproduce it — the URL, the steps, and what you saw.

What we will do

• Acknowledge your report within two working days.
• Tell you what we have found, and what we are doing about it.
• Credit you when we fix it, if you would like us to.

What we ask

• Give us a reasonable chance to fix it before publishing — 90 days is the usual expectation.
• Do not access, modify or delete anyone else’s data. If you come across customer data, stop and tell us.
• Do not run denial-of-service tests, send spam, or use social engineering against our staff or customers.

We will not pursue legal action over research carried out in good faith and within those limits. We do not currently run a paid bug bounty. [UPDATE IF A BOUNTY IS INTRODUCED]