Security

Reporting a vulnerability

If you believe you have found a security issue in ShapeCard, email security@shapecard.ai with “Security” in the subject. Please include the host or component affected, the steps to reproduce it and the impact you observed.

We will acknowledge your report, keep you informed while we investigate, and tell you when it is fixed. We ask that you do not access, change or keep data that is not yours while testing, and that you give us a reasonable time to fix an issue before sharing it publicly.

The machine-readable version of this page is at /.well-known/security.txt.

Scope

In scope: the ShapeCard iOS app and these hosts.

• shapecard.ai
• app.shapecard.ai
• api.shapecard.ai
• admin.shapecard.ai

Out of scope: issues in the third-party services we build on (report those to the vendor), denial of service, and volumetric testing. ShapeCard is pre-launch: cards shown on this site are issued in a test environment.

How we protect data

• Identity numbers are encrypted at rest

  A Social Security number is encrypted with AES-256-GCM under a key used for nothing else, and only the ciphertext is stored. It is decrypted at the moment of an identity check and never logged. A test in the codebase fails if a new place in the code decrypts it.

• Card numbers never reach our servers

  Full card numbers and security codes are shown through the card platform’s hosted frame with a short-lived token. They are not received, proxied, logged or stored by ShapeCard.

• Every platform message is verified before it does anything

  Webhooks from the card and payment platforms we build on are checked against a signature before any data is written, and billing state is re-read from the payment platform rather than trusted from the message.

• Sessions stay on one host

  Sign-in cookies are tied to the host that set them, so a cardholder session cannot be replayed on the admin console or the other way round. Staff tools live on their own host.

• Logs are scrubbed of sensitive data

  Server logs never include identity numbers, card numbers or email addresses. Where a record needs an identity, it carries a hash. Error messages are scrubbed before they are written.

• Every change is reviewed before it ships

  All code reaches production through a pull request that passes automated checks and a code review by a separate, independent AI reviewer, and production deploys get a read-only smoke check.