Security
What we do, and what we do not
You are about to put our tag on every page of your site and let strangers upload pictures into it. That deserves a straight answer rather than a row of badges, so this page has both halves: the controls that exist, and the ones that do not.
Where your money goes
Your advertisers pay into your own Stripe account, connected by OAuth. We never see, handle or store a card number, and no card details pass through our database at any point.
That also means we cannot take your money by accident, and a Stripe dispute is between you and your buyer rather than routed through us. The trade is that you need a Stripe account, or you use vouchers and take payment however you like.
Nothing on this platform holds a balance that belongs to us.
Where your secrets go
Per-tenant secrets, including your Stripe keys, are encrypted before they reach the database. The master key lives in the server process environment, never in the database and never in the repository, so a database copy on its own does not open them.
The encryption is authenticated: AES with an HMAC and a random value per record, using the framework's own security component rather than something we invented. There is a command to rotate the master key and re-encrypt every record.
Account passwords are hashed with bcrypt. Nobody here can read yours, including us.
Controls that exist today
Each of these is in the product now. If you want to check one, ask and we will show you where.
You approve every creative
A banner an advertiser uploads does not serve until somebody on your side approves it. That is the control that matters most on a self-serve portal, because the whole point of self-serve is that strangers put artwork into your pages. The approval screen is in the help centre.
You approve every account
Signup goes register, then confirm the email address, then an admin on your side switches the account active. You can also turn that approval step off if you would rather let people straight in. Either way it is your decision rather than ours.
Everything runs over TLS
The panels, the advertiser portal and the ad request itself. Certificates are issued and renewed automatically, so there is no expiry date for anybody to forget.
Creative files go to object storage
Uploaded artwork is written to object storage rather than served off the application server, so a creative is a file with a content type rather than something executing next to your data.
The demo tenant cannot be written to
We publish demo credentials so you can look before you buy. That tenant refuses writes at the data layer rather than by hiding the buttons, which is why publishing the login is safe.
Two-factor sign-in, on any account
Publisher, advertiser or admin: anyone can switch on an authenticator app from their own profile screen, scan the code and be asked for a six digit code at every sign in afterwards. It is not restricted by role and you do not have to ask us to enable it. The getting started article shows where it lives.
Cross-site request forgery protection is on
Standard framework protection on the panels. The exceptions are the payment webhook and the ad request, which are machine to machine and authenticated differently.
Gaps, named rather than buried
These are the things a security review would find. We would rather you read them here first.
Two-factor guards the door, not every room behind it
Switching it on protects sign in, which is the part that matters most. What it does not do for you is ask again at the moment something sensitive happens. Issuing vouchers creates ad credit out of nothing, and only the platform owner role is challenged for a second code at that point. If you run a tenant, treat the account that can issue credit as the one not to share.
No single sign-on
Sign-in is by email and password with two-factor, not through a directory. SAML and SSO are not part of the platform.
No published uptime commitment
There is no monitored feed behind our status page yet, so there is no number to publish and we are not going to print one that nothing measures. A platform advertising 99.99 per cent is measuring something. We are not, yet.
No third-party audit
No SOC 2, no ISO 27001, no penetration test report to send you, no bug bounty programme. Those cost real money and we are a small product at $29.99 a month. Saying so is more useful to you than a badge that means nothing.
Common questions
What happens if you are breached?
We tell you, by email to the address on your account, and we say what we know rather than waiting until the picture is complete. The same channel we use for planned maintenance. We would rather commit to that plainly than write a paragraph about our incident response framework.
Can you read my advertisers' data?
Technically yes. We run the servers and the database, so people here with production access can read what is in it, exactly as is true of every hosted platform you have ever used. What is not readable is your password, which is hashed, and your Stripe keys, which are encrypted with a key held outside the database. Anyone telling you a hosted product cannot see your data is either self-hosted or lying.
Where is the data held?
On our hosting provider, with uploaded creative in their object storage. There is no region picker on the published plans. If you need your data held in a named jurisdiction by contract, that is an Enterprise conversation, so start it with us first.
Is an ad tag on my site a risk?
Any third-party tag is, which is why it is worth being specific. Ours makes an ad request and writes the returned creative into the slot you defined. The creative is artwork you approved. The main risk in any ad stack is an unapproved creative carrying something it should not, and the answer to that is the approval step above, which is on by default.
Do you sell or share data about my visitors?
No. We do not build an audience graph, we do not sell segments and there is nobody to sell them to: there is no exchange here, only your own advertisers buying your own inventory. What the ad request collects is in the privacy policy.
How do I report a vulnerability?
Write to hello@pyrobid.com with as much detail as you can and we will answer. We have no bug bounty and no formal programme, so there is no payment attached to this, and we would still rather hear from you than not.
Look at it before you trust it.
The demo tenant is open and read only. Fourteen days free after that, month to month, and nothing to sign before you can see the product.
Start free trial14 days free. Your existing ads keep running. Cancel anytime.
The controls described here were read from the Pyrobid application source on 16 September 2026, not from a marketing document. Secret encryption follows the architecture decision record on envelope encryption: one master key in the process environment, per-tenant secrets encrypted into the database with the framework security component. Two-factor sign-in is read from the login action, which sends any account with it enabled to the code screen regardless of role, and from the access rules on the profile screen, which list publisher and advertiser accounts explicitly.