Security and data protection

The principle: everyone in their own space

Each agency, and each individual traveller, sees only the requests, passports and files they provided. Your account is read from your session, never from a page address or a form: changing a number in an address gives access to nothing. In the database, every piece of information is tied to its account, and automated tests check this separation.

Our team opens a file only for the work it requires: reviewing a passport, processing a request. Passport numbers are masked by default; showing a full number requires writing a reason, and leaves a record.

Planned before opening a dedicated account for each agency on the eVisa portal.

Passwords

We never keep a password in readable form, only a fingerprint computed with scrypt, a deliberately slow method, with a random salt for each password. Nobody, not even us, can recover your password from this fingerprint.

A password has at least 12 characters, including one capital letter and one special character. The most common passwords, and those containing your email address, are refused.

Forgotten password: we send a 6-digit code to your email address. It is valid for 10 minutes and works only once. The new password closes all your open sessions. Our answer is the same whether or not the account exists.

Signing in: always an extra code

A correct password is not enough: a 6-digit code is then sent by email. It is valid for 10 minutes, works only once, and we keep only a fingerprint of it. You therefore need both your password and access to your mailbox (two-factor authentication).

If you sign in with an Apple, Google or Microsoft account, that service verifies your identity; we do not send an extra code.

A new code is required for actions that commit you: signing the processing order of a request, downloading a file, changing your password and, for an individual traveller, downloading their visa. This code is valid for 5 minutes, for that single action.

Our team signs in with a password and a code from an authenticator app, every time.

A session closes after 30 minutes without activity, and after 12 hours at most. Its cookie cannot be read by the page's scripts, and we keep only a fingerprint of its content.

Our team's roles

Each team member has a role: review, support, operations or finance. A role opens only the screens of its own work: finance does not see passports under review, support does not see payments. The role is read again from the database on every page, and every refused access is recorded.

Passports and files: private storage

Every passport, photo, file and visa is encrypted before it is stored (AES-256-GCM), with a key of its own. That key is itself encrypted with a main key, kept outside the database. Our host therefore only sees unreadable files, stored under a number, with no person's name.

A file has no public address. It opens only through our application, once signed in: for the agency or individual traveller who provided it, and for our team when it reviews the file. A final file or a visa is downloaded through a signed link, valid for 5 minutes, and is never kept in a cache.

Every time a file is read, we check that it has not been altered; if it has, it is refused.

Encrypted exchanges and secrets

Exchanges between your browser, the site and the application are encrypted (HTTPS). Our servers connect to the database and to file storage over encrypted connections whose certificate is verified.

The secrets we must keep, such as the passwords of the eVisa portal accounts we manage or our team's authentication keys, are encrypted in the same way as files. Sign-in codes and sessions are kept only as fingerprints.

The direct database access offered by our host is closed: only our servers connect to it.

Agreement and signature of each request

At sign-up, the agency accepts the terms and the data processing agreement, and the person registering the agency declares they are authorised to commit it. We keep the version of the texts, the date and the person.

Before each submission, the agency signs the request's processing order with a code received by email. We keep the date, the person, the version of the signed text and a fingerprint of the request's content (SHA-256). The request is then locked: no passport can be added to it.

Audit log

Sensitive actions are written to an audit log: refused sign-ins and locked accounts, password changes, showing a full passport number with its reason, opening a file for review, links to and downloads of files and visas, file erasures.

This log can only be added to: the database refuses to change or delete a line. Only two of our team's roles, operations and finance, can read it, page by page, with no bulk export.

Planned before opening a record of every time a passport image is displayed to the team.

Automatic erasure

A traveller's files (passport, photo, final file, visa) are erased automatically 30 days after the trip's return date. The erasure is real: the file is deleted from storage and its key is destroyed.

Identity information kept in the database (names, passport number, information read and entered) is erased at the same deadline, or 30 days after the final file is delivered if that is later. Without a return date, the deadline falls one year after the traveller was added, plus 30 days.

Only a proof of processing remains, without content: dates, status, nationality and a fingerprint of each file.

Planned before opening early erasure, at your request, from your account.

Safeguards for updates

Each database carries the mark of its environment: a test version of the service refuses to start on the production database, and the other way round.

A database that has received real personal data carries a second mark: test versions of a change then refuse to connect to it, and check this on every request.

Updating the production database requires an explicit confirmation.

Automatic passport reading

To read the text of a passport, we send the image of the page to Google Cloud Vision, a Google service, which returns only text. Our own rules then extract the information, and a member of our team reviews every passport.

To crop the photo to the portal's format, the same service only indicates where the face is; the cropping is done on our side. No face matching is done.

We never use passports to train software. Our copies of the images follow the erasure rule above.

Hosting

The application's data and files are hosted by Supabase in Ireland (eu-west-1 region), in the European Union. The application's servers run at Vercel, in its Dublin region. The public site is hosted by Vercel Inc. (United States).

The data of a request is then sent to the official Saudi portal: this is inherent to a visa application.

The list of our processors and the role of each is on the Privacy and GDPR page.

Protection against common attacks

• An action triggered from another site (CSRF): the session cookie is not sent with a form posted from another site (SameSite attribute).
• Injection into the database (SQL injection): each query passes its values separately, never pasted into its text (parameterised queries).
• Code slipped into typed text (XSS): pages display what was typed as text, never as code (React's automatic escaping).
• Access to someone else's file: every request, file or photo is checked against the session's account; otherwise the answer is “not found”, as for a file that does not exist.
• Repeated password guessing (brute force): after 5 failures in 15 minutes, the account is locked for 15 minutes; a code is blocked after 5 attempts, and at most 5 codes are sent per hour. For our team, the lockout doubles with each series, up to 24 hours.
• Booby-trapped files: a file's type is read from its content, never from its name; only JPEG, PNG, PDF and ZIP are accepted, with a maximum size. A ZIP archive is capped in number of files, size and compression ratio; password-protected archives and PDFs are refused.

Who is responsible for what

For an agency, the agency is the controller of its pilgrims' data; we act as its processor, only on its instructions.

For an individual traveller who entrusts us with their own passports and their family's, we are the controller.

Your rights, and how to exercise them, are described on the Privacy and GDPR page.

Planned before opening a template for traveller information, consent and parental authorisation, given to each agency for its pilgrims.

If an incident happens anyway

Do you think you have spotted a flaw or unusual access? Write to us from the contact page.

If a breach affects data an agency entrusted to us, we inform it without undue delay: as the controller, it is the agency that notifies the CNIL, the French data protection authority, within 72 hours (GDPR, Article 33). If it affects data we are responsible for, we notify the CNIL ourselves within 72 hours when the law requires it, and we inform the people concerned if the risk to them is high (Article 34).