Security
You give AoMadinah your passport, your travel plans, and proof of what you paid. This page explains, without marketing language, how that information is protected — and where the limits are.
1. Account security
- No passwords. Sign-in is a one-time code sent to your phone number. There is no password to guess, reuse, or leak, and no password database to steal.
- Session control. Sign-in tokens are issued per device and refresh automatically; signing out revokes the session on that device.
- Sensitive actions re-verify. Deleting your account from the website requires a fresh SMS verification, not just an existing session.
- Staff accounts are separate. A staff account cannot be deleted through the public form, and staff privileges are granted server-side, never from the app.
2. Encryption
- In transit: every connection between the app, the website, and our backend uses HTTPS/TLS. The website is served over HTTPS with certificates managed by Firebase Hosting.
- At rest: databases, file storage, and backups are encrypted at rest by Google Cloud.
- Secrets: API keys for travel, weather, and scanning providers live only in server-side configuration. They are never shipped inside the mobile app, so they cannot be extracted from it.
3. Who can read your data
Access is enforced on the server, by rules that run on every read and write — not by hiding buttons in the app.
| Data | You | Assigned staff | Other users |
|---|---|---|---|
| Your profile and preferences | Read / write | Read, for support | No access |
| Traveller and passport records | Read / write | Read, for the booking they handle | No access |
| Bookings and quotes | Read; write through the app's workflow only | Read / act, per role | No access |
| Wallet ledger and receipts | Read | Read / record payments, per role | No access |
| Internal staff notes on a booking | No access | Read / write, per role | No access |
Money-affecting and status-affecting operations — recording a payment, issuing a quote, confirming or cancelling a booking, approving documents — do not happen on the phone. They run as server-side operations that check the caller's role, check the booking's expected version to prevent conflicting edits, and write an audit event.
4. Document and upload safety
- Size and type limits. Uploads must be an image or a PDF and within a fixed size limit.
- Content verification. Every uploaded file is checked server-side against its real file signature, not merely its extension or declared type. A file pretending to be an image is rejected and deleted automatically.
- Malware scanning. Where third-party malware scanning is enabled, files are looked up by cryptographic hash and analysed; a file with a confirmed malicious verdict is deleted. See the note in Privacy Policy §9.1 about what that involves.
- Scoped storage paths. Passport images, receipts, and profile photos are stored under per-user and per-booking paths that only their owner and authorised staff can read.
- On-device scanning. Reading text off a passport uses an on-device model. The camera stream never leaves your phone.
5. Payment safety and fraud
Card number, CVV, ATM PIN, online-banking password, or a bank OTP. The app has no field for any of them. If anyone contacts you claiming to be from AoMadinah and asks for one — by call, SMS, or WhatsApp — it is fraud. Do not share it, and report it to support@aomadinah.com.
- Payments are made by bank transfer to accounts shown in the app; you upload proof and our team verifies it against your booking.
- Only staff with the payments role can record, settle, reverse, or refund a payment, and every such action is recorded as an event on the booking.
- Always confirm bank details inside the app before transferring, and treat details sent to you any other way as unverified.
6. App integrity and abuse control
- Firebase App Check — Play Integrity on Android and App Attest / DeviceCheck on iOS — attests that a request comes from the genuine, unmodified AoMadinah app. Requests without a valid attestation are rejected, which blocks scripted scraping of user data.
- Rate limiting on server endpoints, including the travel-search proxy and the delete-my-data endpoint.
- Origin restrictions — the account-deletion endpoint accepts requests only from our own domains, and the staff travel proxy only from the admin console's origin.
- reCAPTCHA guards the SMS step of the web deletion form so it cannot be used to send bulk messages.
- Update gating — we can require an app update when a version has a known security problem.
7. Infrastructure
AoMadinah runs on Google Cloud and Firebase: Authentication, Firestore, Cloud Storage, Cloud Functions, Cloud Run, and Hosting. We inherit Google's physical, network, and platform security, including its certifications (such as ISO 27001 and SOC 2) for those services, and we are responsible for the layers above: access rules, server-side operations, and application code.
Data is stored in Google Cloud regions, principally
us-central1. Backups and point-in-time recovery are
provided by the managed database service.
8. Staff access and accountability
- Staff sign in to a separate admin console with their own accounts and role-based permissions — not a shared login.
- Roles grant only what a job needs; sensitive operations check the role at the server before running.
- Booking actions write an immutable event trail: who did what, when, and to which version of the booking.
- Access is removed when someone leaves the team.
9. If something goes wrong
No system is perfectly secure, and we will not claim otherwise. If a security incident affects your personal data, we will investigate and contain it, notify the relevant supervisory authority where the law requires it, and tell affected users what happened, what data was involved, and what to do about it.
10. What you can do
- Keep a screen lock on your phone and keep the OS updated.
- Never share the SMS code we send you — not with anyone claiming to be our staff.
- Install AoMadinah only from Google Play or the App Store, never as an APK from a link.
- Verify bank details in the app before transferring money.
- Sign out on shared devices, and use “Report a problem” if something looks wrong.
11. Reporting a vulnerability
If you believe you have found a security vulnerability in the app, website, or backend, email support@aomadinah.com with the subject line “Security report”. Please include what you found, the steps to reproduce it, and its impact.
We ask that you:
- give us a reasonable chance to fix the issue before publishing it;
- do not access, modify, or delete data belonging to anyone else — use your own test account;
- do not run denial-of-service tests, spam, or social engineering against our staff or users.
We will acknowledge a report within 5 working days. We do not currently run a paid bounty programme, but we are glad to credit researchers who report responsibly.