Security.

The security of a platform that handles payments, geographic positions and the contact details of students cannot rest on the good conduct of the interface alone. We therefore apply a simple principle: every control is enforced at the lowest possible layer, the one that no manipulation of the client can circumvent.

In practice, access rules, price calculation and the validation of order steps are executed server-side and systematically redo the work rather than trusting what the device sends.

• Encryption in transit — the entirety of the exchanges between our applications, our site and our servers travels over an encrypted connection (HTTPS / TLS). Browsers are instructed to require this encrypted connection by default, including before the first request.
• Encryption at rest — stored data and files are held on encrypted media.
• Passwords — never kept in clear text nor in any reversible form. They are transformed by a one-way hash function: we cannot read them, including internally.
• Sessions — cryptographically signed and revalidated server-side on every protected page. Signing out ends the session on the device concerned.
• Browser hardening — our pages forbid their own framing by a third-party site (protection against clickjacking), lock down how file types are interpreted, restrict the information passed on during an outbound navigation and refuse access to the camera and the microphone by default.

Each role — customer, restaurant, courier, support, administration — sees only what its function requires. This compartmentalisation is enforced at the level of the database itself, so that a query cannot return rows to which its author is not entitled, whatever the way it is written.

• A customer accesses their own order history, their addresses and their preferences, and nothing else.
• A courier accesses only the deliveries assigned to them.
• A restaurant accesses only the orders and the data of its own establishment.
• No personal data is accessible to a visitor who is not signed in. Only catalogue information — menus, opening hours, campus information — is public.
• Administrative access is verified server-side before the page is even displayed, from the stored profile and not from information the user can modify, and is subject to reinforced controls including a two-factor verification.
• A restricted or suspended account is blocked at the door, even if it still holds a valid session.

• Sign-in by one-time code — access by telephone relies on a temporary code, bounded by limits on the number of attempts and by progressive waiting periods.
• Institutional sign-in — university accounts authenticate with their own institution; FORLIK never sees the corresponding password.
• Anti-bot protection — the public sign-in and reset pages are protected by a check verified server-side, which an automated call cannot circumvent.
• No disclosure — our error messages never reveal whether an address or a number corresponds to an existing account.

Two means of payment are open today: cash payment, capped per order — the applicable cap being shown to you at the time of payment — and the FORLIK balance, every movement of which is entered in a traceable ledger. Card payment is not yet open to the public.

FORLIK never stores your bank card number, its expiry date or its security code. That data is kept in none of our systems, in any form.

• Card processing will be carried out by an approved payment provider, a specialist in that business and subject to the standards of the sector. FORLIK, for its part, claims no certification of that kind.
• We will keep only an opaque reference supplied by that provider, together with the network and the last four digits, for the sole purposes of display and accounting reconciliation.
• The strong authentication of your bank (3-D Secure type) will be supported where it is required.
• Sums collected in cash are tracked and reconciled through to their settlement.

Certain data calls for protection above the general encryption of storage. The bank details communicated for the payment of earnings are part of it: they are encrypted individually, by means of a dedicated key, which may be renewed.

Consulting them in clear text is governed cumulatively:

• it is reserved to authorised administrators, within their own perimeter only;
• it requires a written reason to be entered;
• it is capped in number per hour, individually and overall;
• it is logged in an immutable journal.

Identity documents and payment receipts are kept in private storage areas, not reachable through a public address, with restrictions on the formats and the sizes accepted.

The position of a courier is transmitted continuously during an active delivery only: the application stops emitting it as soon as the delivery is finished or the courier goes offline. The real-time tracking stream is not recorded.

Access to location presupposes an explicit authorisation at the level of your operating system. You may withdraw it at any time from the settings of your device.

• Prices recalculated server-side — amounts, options and extras are recalculated from our reference data. A total transmitted by the device is never accepted as it stands.
• Protection against duplicates — every order attempt carries a unique key which makes it structurally impossible to record the same order twice, including in the event of a loss of network or a double tap.
• Verified confirmations — the handover of an order is validated by a code or a QR specific to that order, checked server-side against the identity of the person presenting it.
• Governed transitions — the life cycle of an order accepts only legitimate steps, in order, and only from the persons concerned.

• Sensitive administrative and financial operations — foremost among them any consultation of bank details — are recorded in an append-only journal, readable by administrators alone and written exclusively by server-side procedures.
• Each entry identifies the author, the action, the object concerned and the timestamp.
• A continuous automated supervision permanently assesses the proper running of the service and opens prioritised incidents, passed on to the operations team.

Logs are kept for as long as is necessary for the purposes of security, of evidence and of compliance with our legal obligations.

In the event of a security incident, our response follows four stages:

• Contain — revocation of sessions and suspension of the access concerned.
• Qualify — establish the nature of the data affected and the risk incurred.
• Notify — inform the CNDP (the Moroccan personal data protection authority) and, where the risk to your rights warrants it, the persons concerned, within the time limits laid down by the applicable regulations.
• Correct — remedy the cause and draw lasting conclusions from it.

The operation of the platform relies on a restricted number of specialised providers — hosting, payment processing, routing of messages and notifications, map data, anti-bot protection.

They are selected on security criteria, act only for the purposes strictly necessary to their assignment and have access only to the data that assignment requires. They are not authorised to exploit your data either on their own account or for advertising purposes.

The detail of the categories of recipients, the hosting locations and the framework governing transfers appear in our privacy policy. The named list of our processors is provided on request at support@forlik.com.

Part of the risk lies beyond our reach. A few habits are enough to cover it:

• Choose a password that is long and specific to FORLIK, never reused from another service.
• Never pass on the code received by SMS: it is enough to access your account. FORLIK will never ask you for it, any more than for your password, by telephone, message or email.
• Check that you are indeed on forlik.com before entering your information.
• Sign out after use on a shared device.
• Report without delay any unusual activity on your account to support@forlik.com.