Security questionnaire for an audio tool: what to ask, and our answers, including the noes

Turning articles into audio sounds like a front-end job: drop a player on the page and move on. From a security reviewer's seat it looks different. The vendor receives your copy before it is published, runs a script on your pages, holds a key that can act on your account, and in some modes fetches URLs on your behalf. Those are four doors worth checking before anyone signs.

Data residency (where the text goes, who processes it, how long it is kept) is covered in a separate piece on where your text actually goes. This one covers the rest of a typical vendor security questionnaire: credentials, access control, what the service can be tricked into doing, and what it cannot yet show you. Each answer below is what the code does, as published on our security page.

Who ever sees the API key?

Leaked keys are the boring, common incident. Someone pastes a key into a support ticket or a chat thread, and it stays there for years.

Our WordPress plugin never displays its key. During setup it trades a one-time code, valid for two minutes, for its own key, server to server, so nobody on your team has a chance to copy it anywhere. Each site gets its own key, tied to that site: revoking a staging site's key does not touch production. Keys are stored hashed, which means we cannot read one back to you, only replace it, and revocation is self-service from the client area.

If installation is your main concern, the WordPress plugin page lists what the plugin writes to your site and what it leaves alone.

Does our site need to accept inbound connections?

With the plugin or the API, no. Traffic goes from your server to ours, so a locked-down staging environment or an intranet works without a firewall exception. Two honest caveats. RSS feed discovery runs the other way by definition: we read a public feed, so that mode assumes a reachable site. And if you opt into the "audio ready" webhook, we call an endpoint you choose, with a signature your server can verify (how the webhook signature works).

Will the service fetch URLs that users type in?

This question is missing from most questionnaires, and it should not be. Any feature that accepts a URL (an article to estimate, a feed to follow, a jingle, a webhook target) makes the vendor's servers fetch something on request. Without care, that turns into server-side request forgery: someone points the service at an internal address and reads what comes back.

What we do: customer-supplied URLs must be https; localhost and private, loopback, link-local and carrier-grade NAT ranges are refused, including hostnames that resolve to them; and the connection is made to the address that was checked, not to a second lookup. The part that matters most is redirects. We no longer let the HTTP client follow them on its own. Every hop is revalidated by the same filter, with a cap on the number of hops.

We tightened this in August 2026 after finding that a plain redirect got around the original check. We mention it on purpose. A vendor that has never found a hole in its own product has usually not looked very hard.

Are roles enforced, or just hidden?

There are three: owner, administrator, member. A sub-editor has no business in billing, and the restriction is enforced by the server, not just removed from the menu. That distinction is the follow-up question to put to any vendor showing you a roles screen, because a hidden button with no server check is one direct API call away from being pressed.

What does the player leave on readers' devices?

No cookies, no listener ID, no browser fingerprint. Two values are written to the listener's own browser and we name them rather than round them away: their playback position, so they can resume, and their accessibility settings. Neither is sent to us. The IP address is used for one minute, in memory, to rate-limit play counts, and never reaches the database.

The gaps, stated before you find them

A questionnaire is only useful if the noes are as precise as the yeses. Ours:

• No ISO 27001 certification. If procurement treats it as a hard gate, we will not pass, and it is better you know now. We do answer written security questionnaires in full and accept the matching contract clauses.
• No customer-facing access log. We log our own admin actions on accounts, but you cannot review sign-ins or your team's actions from the client area. For a newsroom sharing one account, that is a real gap.
• No uptime commitment with penalties in the online plans, and no published uptime figure, because we do not yet run an external probe with history to back one. The status page says what is actually checked and keeps a dated incident log. Service levels are negotiated in quoted contracts.
• No bug bounty and no coordinated-disclosure page. Security reports sent to us directly go to the front of the queue.
• Not European end to end. Storage and text preparation are in the EU; speech synthesis is not yet. Until it is, the corresponding option stays greyed out in the client area, and the code makes that call, not a marketing page.
• No self-hosting of audio files. That option was once advertised on our site without existing. The claim was removed in August 2026.

Using this list on anyone

Send these six questions in writing to every vendor on your shortlist, including us, and grade the precision of the answers rather than their tone. "We take security very seriously" answers none of them. "The setup code expires after two minutes and works once" can be checked.

One last question worth adding at the end: ask for the most recent security fix and its date. A specific, dated answer tells you more than a page of badges, because it shows that someone is looking.

Read next

• Breton, Basque, Corsican, Alsatian: why French text-to-speech trips on regional names
• A woman's or a man's voice for a quote: what French grammar reveals about who is speaking
• An audio provenance certificate: proving what produced the spoken version of an article