Security
Data Security
How the site is structured to reduce checkout and personal-data risk.
Security overview
The site separates public web files from sensitive configuration. The public document root should be set to the /public folder so that .env, /lib, and /storage are not directly web-accessible.
Payment security
Payments are handled through secure embedded checkout on the STEP assistance page. Card details are entered into a third-party secure payment frame and sent directly to the payment processor. This site stores only checkout references and payment status, not full card numbers or CVC values.
Application safeguards included
- Payment secret keys are stored in
.env, outside the public web root. - Server-side validation for all form fields.
- CSRF token validation for the enrollment form.
- Security headers for clickjacking, MIME-sniffing, referrer policy, and content sources.
- SQLite data storage in the private
/storagedirectory. - Payment webhook signature verification support.
Operational requirements before launch
- Force HTTPS for all pages.
- Set file permissions so the web server can write only where required.
- Limit production access to
.env, database backups, logs, and server credentials. - Rotate payment keys if a secret is exposed.
- Configure backups, retention, and secure deletion for travel intake records.
- Review logs so payment or personal data is not accidentally written to error output.
Incident response
Before production use, create an incident response process that covers triage, containment, key rotation, forensic review, customer notification, regulator notification when legally required, and post-incident remediation.