Skip to main content
Security

How we protect the data you give us.

Card details touch our servers for a fraction of a second — and then they're gone. Here's the engineering and the operational playbook behind that promise.

Last reviewed: May 7, 2026

Principles we won't bend

Treat card details as borrowed, not owned

From the moment your form submission lands on our servers, the card details are tagged as ephemeral: they're forwarded to the issuer, the response is rendered, and the values are dropped from process memory. Nothing about the request is written to long-term storage.

Defaults that fail closed

Plain-HTTP requests are rejected at the edge. Logs strip card-shaped patterns before they're written. Rate limits are enforced before our application code ever sees a request. If the safest behavior isn't the default, we treat that as a bug.

Boring is a feature

We use boring, well-understood building blocks — TLS 1.3, HTTP-only cookies, parameterized requests to issuer APIs, audited libraries. We don't roll our own crypto, and we don't ship clever code where simple code will do.

What's in the stack

Transport encryption

TLS 1.3 with HSTS and a strict Content Security Policy. Plain-HTTP requests are 308-redirected to HTTPS at the load balancer.

Form protection

Every form submission carries a same-site CSRF token. The contact form additionally has a hidden honeypot field that catches naive bots before our app code runs.

Storage

Card numbers, expiration dates, and security codes are never persisted. Access logs hold IP and user-agent for 14 days for diagnostics, then are purged on a rolling cron.

Access controls

Two-factor authentication is mandatory for any team account that can reach production. Production access is least-privilege — there is no shared admin role — and every access event is audit-logged.

Dependency hygiene

Automated alerts for known CVEs in our dependencies. Patches that affect security paths are tested in staging and pushed within 48 hours.

Incident response

If a security event occurs, we follow a written runbook: contain, assess, notify affected users, publish a public post-mortem within 30 days, and adjust controls so the same class of issue doesn't recur.

Responsible disclosure

If you've found a vulnerability, we want to hear about it before anyone else does. Here's how the process works.

  1. 1

    Email us first

    Send the report to support@mygift-giftcardmallai.com with the subject line tag [Security]. PGP key on request.

  2. 2

    We acknowledge within 2 business days

    You'll get a real reply confirming we received the report and a tracking ID for follow-ups.

  3. 3

    Coordinate disclosure timeline

    We'll work with you on a reasonable disclosure window — typically 90 days from the report. If we need more time for a complex fix, we'll explain why.

  4. 4

    Recognition

    Researchers who report valid issues are added to the public hall of fame on this page (with permission). We don't yet operate a paid bounty, but that's on the roadmap.

Out of scope

We're a small team, and the items below either aren't useful as findings or are actively harmful. Reports that fall in this list won't be acknowledged.

  • Brute-force attacks against the balance form using card numbers you don't own — that's not testing our security, it's testing the issuer's, and it's against the law in most jurisdictions.
  • Denial-of-service or volumetric attacks against the production site.
  • Social engineering of GiftCardMall staff, contractors, or vendors.
  • Findings that depend on a victim already having malware on their device.
  • Reports auto-generated by scanners with no proof of exploitability.

Reporting a vulnerability?

Use the subject tag [Security] so it gets routed correctly.

Contact us