You own the accounts
On client work, the repositories, cloud accounts, domains and documentation are yours from day one, and handover is documented. Because the accounts are yours, you grant our access and you can withdraw it.
Company and security information
Company details for CODEHARDY LTD, how we handle security, and what we provide during a supplier evaluation.
Company details
The registered details a supplier onboarding form asks for.
- Legal name
- CODEHARDY LTD
- Registered in
- England and Wales
- Company number
- 15543466
- Registered office
- 167-169 Great Portland Street, 5th Floor, London, England, W1W 5PF
- VAT registration
- GB487409745
- Trading names
- Popup Pal is a trading name of CODEHARDY LTD
- Enquiries
- marcos@codehardy.com
How we handle security
The first practice below is a commitment we make on client work. The rest describe how we build Popup Pal, our own product, today, and we apply them by default on client work. Where your organisation has its own security standards, we work to those. This page describes how we work. It is not a certification or an audit report.
Sign-in and sessions
On Popup Pal, sign-in attempts are rate limited inside the credential check itself, so skipping the login form does not skip the limit. One-time email codes are stored hashed, capped at five attempts and consumed once. Changing an email address or password invalidates existing sessions, and sensitive credential changes need a sign-in within the last 15 minutes. We carry the same rules into client systems that manage their own sign-in.
Rate limiting that fails closed
Popup Pal applies its rate limits through a shared counter store. In production, if that store is unreachable, rate-limited requests are refused instead of being let through. Public forms also sit behind a bot check, and the server verifies the result, including the hostname it was issued for. This is our default on client work.
Card data stays with the payment provider
Popup Pal takes payments through Stripe Checkout, so card details are entered into Stripe's form and our application has no card fields of its own. Webhooks are signature-verified, matched against the amount and currency we recorded, and de-duplicated by event ID. Checkout and refund calls carry idempotency keys, so a retried request is not applied twice. This describes engineering practice. It is not a PCI attestation. On client work that takes payments, we use the provider's hosted card entry by default.
Input validation and output escaping
Popup Pal validates incoming data against schemas on the server. CSV exports neutralise cells that a spreadsheet would treat as a formula. Text placed into emails and structured data is escaped. We apply the same checks by default on client work.
Secrets and configuration
In production, Popup Pal refuses to start unless each of its three application secrets is at least 32 characters long and different from the others. The same guard blocks a mix of live and test payment keys. We add the same start-up checks to client systems by default.
Checks on every change
Every pull request on Popup Pal runs lint, unit tests, integration tests against a real Postgres database, a dependency audit and a production build. The pipeline fails if the audit reports a high or critical vulnerability. Security-critical packages are pinned to exact versions. Browser-driven tests run against staging and are not part of this pipeline. We set up the same pipeline by default in client repositories.
Private files
Compliance documents uploaded to Popup Pal go to a separate private store. Downloads go through a route that checks the requester's permission, not a public link. Uploads are limited to an allowlist of file types and a size cap. We handle sensitive uploads the same way on client work.
Error monitoring that scrubs personal data
Popup Pal's error monitoring records errors only. Each event is rebuilt from an allowlist of fields, and messages are scrubbed of email addresses, IP addresses, URLs and tokens before they are sent. Session replay and tracing are switched off. We configure monitoring the same way by default on client work.
Security headers, and one gap
Popup Pal sets headers on every route that stop MIME sniffing, withhold the referrer and switch off browser features the product does not use. Framing is limited to the same origin, except on the embed routes that are built to be framed. A strict script Content Security Policy is not in place yet. Our own security review lists it as follow-up work. We set the same baseline headers by default on client work.
Written security reviews
We write dated security reviews of Popup Pal and keep them in the repository next to the code. They separate what was checked locally from what was verified on the hosted system. The September 2026 review covered a dependency audit and a scan of the full commit history for embedded credentials. These are our own reviews, not independent penetration tests. On client work, any review notes we write go into your repository, because the documentation is yours.
Available during supplier evaluation
More detailed supplier information is provided during evaluation rather than published in full.
- Company details for your supplier onboarding forms
- The named team proposed for your project, as set out in the proposal
- Written answers to your supplier or security questionnaire
- More detail on any practice described on this page
Ask for any of these in your enquiry, or email marcos@codehardy.com.
Evaluating us as a supplier?
Say so in your enquiry and list what you need. We reply within one working day.