Security

Access and authentication

• Passwords are never stored in the clear: only a bcrypt hash is kept, computed with a high work factor that makes brute force expensive.
• A password must be at least eight characters and combine upper case, lower case, a digit and a special character.
• Two-factor authentication is available through an authenticator app (TOTP), by email or by WhatsApp, with single-use backup codes.
• A PIN code, also stored as a hash, is required to switch users at the counter and to confirm sensitive actions.
• After ten failed sign-in attempts the account is locked for thirty minutes.
• Session tokens expire after twenty-four hours and are revoked immediately on sign-out and when an account is deactivated: a revoked token is refused even if it has not yet expired.

Permissions and separation

• Rights are granted module by module, from role templates (owner, pharmacist, technician) that the owner can refine for each member of the team.
• Every API request is checked three times: the identity behind the token, the permission on the module being reached, and an active subscription.
• Access control is enforced server-side. The interface hides what you may not see, but that is not where the security lies.
• A pharmacy's customer records, sales and financial data are not published to the inter-pharmacy network. Forum contributions and online presence status are visible to other users - that is their purpose.

Auditability

• An activity log records sign-ins, sign-outs, authentication failures, lockouts and user switches. Its entries can be neither modified nor deleted, including by an administrator: that is what gives it evidential value.
• A readable login history shows, for each attempt, the date, device, browser and approximate location derived from the IP address, so that unusual access stands out.
• PIN confirmations are timestamped and tied to the action they authorised.

Protecting traffic and infrastructure

• All traffic is encrypted over HTTPS and forced server-side. Browsers receive an HSTS directive preventing them from falling back to an unencrypted connection.
• Security headers restrict framing of the site by third parties, content-type sniffing, and URL leakage to external sites.
• Request rates are limited per IP address and per account, with tighter thresholds on sign-in, two-factor authentication, password reset and the public forms, to slow automated attacks.
• Traffic between the application and the API is restricted to declared origins; the marketing site's public forms have a separate, write-only path that can reach no authenticated data.
• Uploads are limited to images, in three defined areas, and the file type is determined by the server rather than taken from the name supplied by the browser.
• Passwords, tokens, secrets and one-time codes are excluded from application logs.
• Every code change passes static security analysis and a check for known vulnerabilities in dependencies before it is merged.

What we do not do yet

We would rather write this down than let silence make the promise:

• Apotheca holds no security certification (ISO 27001, health data hosting or equivalent) and claims none.
• Data is not encrypted at the database column level: authentication secrets are hashed, and the rest rests on access control and infrastructure protection.
• No external security audit or independent penetration test has been carried out to date.
• The CNDP formalities applying to health-related processing and to transfers outside Morocco are not complete. Their status is set out in our privacy policy.

Reporting a vulnerability

If you believe you have found a security flaw in https://apotheca.ma or https://app.apotheca.ma, write to [email protected] describing the problem and the steps to reproduce it. We acknowledge receipt within five working days.

We ask that you do not disclose the flaw publicly before we have been able to fix it, that you do not access data that is not yours, and that you degrade neither the service nor anyone else's data. We will not pursue people who report in good faith while respecting these rules.

In the event of an incident

Should a security incident affect a client pharmacy's data, that pharmacy would be informed without undue delay, with the nature of the incident, the data concerned, the measures taken, and the steps it must itself take towards the individuals concerned and the CNDP as data controller.