Security

Payments

We never handle or store your full card number. Payment is taken and processed directly by Stripe, a PCI DSS Level 1 certified payment processor — the highest level of certification in the payments industry. We only ever receive a booking reference and payment status back from Stripe, over a webhook whose signature we verify on every request so we can’t be spoofed by a request that didn’t actually come from Stripe.

Passwords and account access

• Password hashing — operator, admin and traveler passwords are never stored in plain text. We hash them with bcrypt before they ever touch the database, so even we can’t read your password back.
• Login throttling — sign-in attempts are rate-limited per IP address, and the admin console additionally locks an account out for a cooldown period after repeated failed password attempts against it, regardless of where the attempts come from.
• Self-hosted CAPTCHA — admin login is protected by a CAPTCHA we generate and check ourselves. We deliberately don’t use a third-party CAPTCHA provider there, so no outside service ever sees that a login attempt happened.
• Session cookies — signing in sets a single session cookie that is httpOnly (invisible to page scripts), Secure (sent only over HTTPS) and SameSite=Lax (not attached to cross-site requests). Every operator and admin page re-checks that session against the database on every request, rather than trusting a value cached from an earlier page load.

Data in transit and at rest

All traffic to the site is encrypted over HTTPS, with HSTS enabled so browsers refuse to fall back to an unencrypted connection. Check-in/check-out vehicle photos are stored outside the web-servable part of the app — they’re never reachable by a direct URL — and are only ever sent onward as an email attachment to you and the operator handling your booking.

Application security practices

• Every server action and API route re-validates its inputs and re-checks the caller’s permissions — the UI hiding a button is never treated as the security boundary.
• Database access goes through parameterised queries throughout, to guard against SQL injection.
• Access to booking, operator and account data in the operator and admin consoles is restricted to authenticated staff with the relevant role.
• Sensitive configuration (API keys, database credentials, webhook secrets) is held in environment variables, never committed to source control.

Operator vetting

Parking operators don’t appear on the site automatically — every application is reviewed by our team before a lot goes live, and we can suspend a listing at any time if a problem comes up.

Reporting a security issue

If you believe you’ve found a security vulnerability on this site, please report it to us privately at ops@airportparkingexchange.com rather than disclosing it publicly, and give us a reasonable amount of time to investigate and fix it before sharing details elsewhere. Please avoid accessing, modifying or deleting anyone else’s data while testing, and don’t run automated scanning that could disrupt the service for other users — we’re happy to work with good-faith researchers.

Related

See our Privacy Policy for what data we collect and how we use it.