How CardParse is built.

Keeping one customer out of another

Every record belonging to an organisation carries that organisation, and every query is filtered by it. That filtering is enforced by the database through row level security, using a role that cannot bypass it, so a mistake in application code cannot expose another customer’s contacts. Attempts to read across that boundary are covered by tests that run on every change.

Accounts and access

• Passwords are hashed with Argon2id, checked against known breached password lists at signup, and never stored or logged in readable form.
• Sessions are held in the database rather than as signed tokens, so access can be revoked instantly rather than waiting for a token to expire.
• Sessions have both an idle and an absolute timeout, and you can see and revoke every active session from account settings.
• Staff access to the administration surface requires a second factor with no bypass, and every action taken there is recorded with who did it and why.

The mobile app

• The app authenticates with an API key, never with a session cookie, so the scanning endpoints cannot be reached by a browser that happens to be signed in.
• Keys are shown once at creation and stored only as a hash, so a copy of our database does not yield working keys.
• On the phone the key is held in the iOS keychain, marked as readable only while the device is unlocked and only on that device, so it does not travel in a backup.
• The pairing code is checked against a list of hosts we run before it is accepted, so a forged code left on a stand cannot point the app at somebody else’s server.

Card photographs

• Stored under a random name that cannot be guessed from the contact, encrypted at rest, and never public.
• Served through short lived signed links from an origin that shares no cookies with the application.
• Location metadata is removed on the phone before upload and removed again on arrival.
• Deleted seven days after the scan.

The application itself

• Served only over HTTPS, with a strict content security policy that permits no inline script.
• Every request body, query and webhook payload is validated against a schema before anything reads it.
• Text read from a card is treated as untrusted, because it comes from a photograph of an object anybody can print. It is escaped on display and neutralised on export so a card cannot smuggle a formula into your spreadsheet.
• Payment card details go to Stripe directly and never pass through our servers.
• Dependencies are updated weekly and every change must pass type checking, linting, tests and a build before it can deploy.

Telling us about a problem

Write to hello@cardparse.com. We will confirm we have it within one working day and keep you informed until it is closed. We will not threaten anybody who reports something in good faith, and we are happy to credit you if you would like that.

Please do not test against another customer’s data or run anything that would degrade the service for people using it. Ask us first and we will agree what is in scope.