Injection and scripting
Database access goes through the framework's query builder and ORM with bound parameters, never string-built SQL. Output is escaped by default, every form carries a CSRF token, and every input is validated on the server.
Security
Security: what your security team gets before the demo
This page is written for the people who approve a vendor: your security team, your IT lead, your auditor. It says how we build online stores, ERP and CRM systems and web platforms, how we host them, who can reach them, and what we hand you to check it all. Nothing here is a claim we cannot show you.
SCROLL
Hardened first
Firewall, key-only SSH, brute-force blocking, automatic security updates and audit logs on every server before anything goes live.
3-2-1 backups
Nightly encrypted backups, three copies on two kinds of storage, one off-site, one immutable, with restores tested on a schedule.
One client, one instance
Your system runs on its own server, with its own database, keys and backups. It is never mixed with another client's.
Who this is for
Read this before the demo, then test it yourself
MrZaKaRiA is a small software studio run from Casablanca. We design and build online stores, ERP and CRM systems, web platforms and the servers they run on, and we operate them after go-live. A security review of a small vendor comes down to three questions: how is it built, how is it hosted, and who can get in. This page answers them in order, in the detail a reviewer needs.
Two things are deliberately missing. We do not hold a SOC 2, ISO 27001 or PCI DSS attestation, and we do not describe practices we do not follow. What we offer instead is evidence: written answers to your security questionnaire, the architecture and data flow of your deployment, the hardening and backup set-up of your server, and a staging instance that your team can scan or penetration-test before you approve anything. If a control you need is not on this page, tell us before the demo and we will say plainly whether we can meet it.
01 / How we build
Secure by the way it is written
Every system we build runs on Laravel and Next.js, frameworks with protections built in. These are the practices behind every build, store or ERP alike.
Sign-in
Passwords are stored as bcrypt hashes. Sign-in is rate-limited against brute force. Admin panels take a second factor, an authenticator app or an emailed code, and products such as WaveTicket force a password change and two-factor set-up before first use.
Roles and permissions
Access is by role, with per-route permissions on what each role may see and do. Where the product has it, such as RAIN Store, admin actions are written to an audit log that your team can review.
Secrets and keys
Credentials, API keys and encryption keys live in environment files on the server, outside the code and outside the repository. Each deployment has its own keys. Outgoing webhooks are signed (HMAC) so the receiver can verify them.
Browser hardening
Every response carries HTTP Strict Transport Security, a Content Security Policy with frame-ancestors, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy headers. Sensitive fields that products store, such as remote-access credentials in WaveTicket, are encrypted at rest.
Dependencies and updates
Package versions are pinned and updated as part of operations, with framework security releases applied as they appear. Deployments run in containers that can be rolled back to the previous version if an update misbehaves.
02 / How we host
A hardened server of your own
Hosted systems run on a server dedicated to you, with the provider and region you choose, or on your own hardware. This is how each one is set up and kept.
Isolated per client
Your system has its own server or VPS, its own database, its own keys and its own backups. No shared hosting, no shared database, no other client's code on the machine.
Hardened in sequence
Before go-live: UFW firewall with only the needed ports open, SSH by key only with password login off, fail2ban against brute force, unattended security upgrades, and audit logs kept.
TLS everywhere
Every host gets its own certificate, renewed automatically. Traffic is HTTPS only, with HSTS so browsers never fall back to plain HTTP.
Backups you can restore
Nightly encrypted backups on the 3-2-1 rule: three copies, two kinds of storage, one off-site in another region. One copy is immutable for a retention window, even to an administrator, so ransomware cannot reach it. Restores are tested on a schedule, not assumed.
Monitoring and alerts
CPU, memory, disk, network, process health and certificate expiry are watched, with alerts before limits are hit and before users notice. A written runbook describes the server and how to recover it.
Remote access
Administration happens over SSH with named keys, one per person. Where a private service must be reached from outside, it goes through an encrypted tunnel with no open inbound ports, not a port forwarded on the firewall.
03 / Your data
You own it, you decide where it lives
Ownership. Your data sits in your own database, on your own instance. On a custom build you also receive the repository, the documentation and a walkthrough at handover. You can export your data at any time, in the formats the product supports, and you can migrate, take the system in-house or shut it down without asking our permission.
Location. The server runs with the provider and in the region you choose: the EU, the UK, North America, the Gulf, or your own hardware on site. Backups go to a second location you agree with us. Nothing is moved to another region without your written agreement.
Privacy. For a hosted system we act as your processor: we handle your data only to run the service for you. We sign a data-processing agreement on request, list the sub-processors of your deployment (the hosting provider, the backup location and the email service), and configure region, encryption at rest, audit logging and retention for the rule that applies to you. Products with it, such as RAIN Store, offer GDPR data export.
End of engagement. When you leave, you receive a final export, and data on our side is deleted after the agreed retention period, with written confirmation.
04 / Evidence
What we hand your security team
Ask for any of these before the demo. Each one comes in writing, from the person who built or runs your system.
| Item | What you get | When |
|---|---|---|
| Security questionnaire | Written answers to your questionnaire: SIG Lite, CAIQ or your own form, control by control, with 'no' where the answer is no | Before the demo, within one week of receiving it |
| Architecture and data flow | A description of your deployment: components, where data is stored, what talks to what, and over which ports and protocols | Before the demo |
| Staging instance for your tests | A staging copy your team may scan or penetration-test in an agreed window. Critical and high findings are fixed and re-tested before go-live | During evaluation |
| Hardening and backup record | The server's hardening checklist and the log of the last tested restore | Before go-live, then on request |
| Access list | The named people at MrZaKaRiA who can reach your system, how (SSH key, admin account) and why. Access is removed when a person's role ends or at handover | Before go-live, then whenever it changes |
| Data-processing agreement | A signed DPA with the sub-processors of your deployment listed | Before go-live |
| Incident notice | If a security incident touches your data: containment first, notice to your contact without undue delay, then a written report with cause, impact and the fix | As it happens |
05 / The review
How a security review runs with us
Five steps, usually inside two to three weeks, in parallel with the commercial conversation.
01
Send your requirements
Your questionnaire, your policy, or a list of the controls you need. A short call to clarify scope is enough.
02
Written answers
You receive the questionnaire answered, the architecture of the proposed deployment and this page's controls mapped to your list, with any gaps named.
03
Your tests
A staging instance is set up for your team to scan or penetration-test in an agreed window. You can also review the code of a custom build.
04
Fixes and re-test
Critical and high findings are fixed and re-tested before go-live. Lower findings are scheduled and tracked in writing.
05
Go-live with an access list
The production server is hardened, backed up and monitored as described above, with the named access list and the DPA signed before the first user signs in.
FAQ
Questions security teams ask
The questions we hear from IT and security reviewers, answered plainly.
No. We are a small studio and we do not hold a SOC 2, ISO 27001 or PCI DSS attestation. We answer your questionnaire in writing, document your deployment, open a staging instance to your own testing, and support your audit of the controls on this page.
2
Where is our data hosted, and who else is on the server?
On a server dedicated to you, with the provider and in the region you choose, or on your own hardware. Nobody else: one client, one instance, with its own database, keys and backups.
3
Who at MrZaKaRiA can access our system?
Named people only, listed in writing, each with their own SSH key and admin account. No shared logins. Access is removed when a person's role ends, and at handover if you take the system in-house.
4
Can our team run a penetration test or a vulnerability scan?
Yes. We set up a staging copy and agree a window. Critical and high findings are fixed and re-tested before go-live; the rest are scheduled and tracked in writing. On a custom build you can also review the code itself.
5
How are backups done, and have you ever restored one?
Nightly encrypted backups on the 3-2-1 rule, with one copy off-site in another region and one immutable for a retention window. Restores are tested on a schedule, and the log of the last tested restore is available on request.
6
Do your systems support two-factor authentication and single sign-on?
Two-factor, yes: admin panels take an authenticator app or an emailed code, and products such as WaveTicket require it for every user. Single sign-on with your identity provider is not built in today; it can be added to a custom build as scoped work.
7
What happens if there is a security incident?
We contain it first, notify your named contact without undue delay, and follow with a written report: what happened, what data was involved, what we fixed and what changes to prevent it. If personal data is involved, the notice is timed so you can meet your own reporting duties.
8
What do we get at handover if we leave?
A final export of your data, and on a custom build the repository and documentation. Data on our side is deleted after the agreed retention period, with written confirmation.
Next step
Send your security questionnaire before the demo.
Attach your questionnaire or list the controls you need. You get written answers, the architecture of your deployment and a staging instance your team can test, usually within a week.