Our own security posture — publicly auditable
DataSouv sells compliance and security. The bare minimum is to apply it to ourselves and make it verifiable. This page documents our public posture: HTTP headers, hosting, trackers, responsible disclosure channel. No staging: a curl -I https://datasouv.ma gives you the same headers as those listed here.
Posture
Eight verifiable commitments
Each of these points is observable from the outside, without privileged access to our infrastructure. If your observation does not match, let us know: it means we have regressed.
Strict Content-Security-Policy
No external script allowed. No Google Tag Manager, no Meta pixel, no third-party chat, no external A/B testing. Every off-origin resource is blocked by default.default-src 'self'
HSTS preload
Strict-Transport-Security with includeSubDomains and preload: no chance for an HTTPS → HTTP downgrade, including on first browser contact, including on future subdomains.max-age=63072000; includeSubDomains; preload
Zero trackers, zero analytics cookies
No tracking cookie, no third-party analytics (Google Analytics, Plausible cloud, Matomo cloud, etc.). Only a strictly necessary cookie for language preference.0 third-party trackers
EU hosting
Site hosted on Vercel with functions executed in EU regions (Frankfurt/Paris/Dublin/Stockholm). Vercel US control plane covered by SCCs. No systematic transfer outside the EU for public content, no operational dependency on a US CDN or non-EU SaaS.europe-west4 / Netherlands
Cross-Origin Isolation
Cross-Origin-Opener-Policy: same-origin, Cross-Origin-Embedder-Policy: credentialless, Cross-Origin-Resource-Policy: same-origin. The site is isolated from the cross-browsing context.COOP + COEP + CORP
Email anti-spoofing
SPF, DKIM and DMARC configuration on the datasouv.ma domain. Public DMARC policy, aligned with what we require from our clients in audits.SPF + DKIM + DMARC
security.txt RFC 9116
Public responsible disclosure file compliant with RFC 9116. Dedicated secure channel, supported languages, published disclosure policy./.well-known/security.txt
Locked Permissions-Policy
All sensitive APIs (camera, microphone, geolocation, sensors, payment, USB, MIDI, accelerometer, etc.) are explicitly disabled at the browser level, regardless of the code.17 APIs disabled
HTTP headers in plain text
What your browser receives, line by line
Configuration applied to all site routes via next.config.ts. Verifiable with curl. No promotional header, no X-Powered-By, no Server: …
| Header | Value |
|---|---|
| Content-Security-Policy | default-src 'self'; … |
| Strict-Transport-Security | max-age=63072000; includeSubDomains; preload |
| X-Content-Type-Options | nosniff |
| X-Frame-Options | DENY |
| Referrer-Policy | strict-origin-when-cross-origin |
| Permissions-Policy | camera=(), microphone=(), geolocation=(), … |
| Cross-Origin-Opener-Policy | same-origin |
| Cross-Origin-Embedder-Policy | credentialless |
| Cross-Origin-Resource-Policy | same-origin |
| X-DNS-Prefetch-Control | off |
| X-Permitted-Cross-Domain-Policies | none |
What we commit to upholding, durably
These commitments are public and binding. If we depart from them, you can call us out publicly — including reporting the breach to the CNDP if it is regulatory in nature.
- Targeted Mozilla Observatory score: A+
- No third-party trackers, no external analytics cookies
- Records of processing published and kept up to date
- Responsible disclosure framed (RFC 9116)
- Informal bug bounty: safe harbor for good-faith researchers
- Monthly dependency updates, weekly npm audit
- Server-side data with EU providers only and signed DPAs
- No systematic dispatch to Cloudflare, Google Fonts runtime, or any other third-party CDN
Frequently asked questions
About this public posture
Why publish your own security posture?
Because you cannot sell compliance and security while staying opaque about your own practices. The Moroccan market lacks technical transparency: most security agency websites use Google Analytics, Google Fonts at runtime, and have no CSP. Our exemplarity is a moral contract toward our clients.
Have you identified any limits?
Yes, and it is public. (1) 'unsafe-inline' on style-src is required as long as Tailwind v4 injects inline CSS; we will switch to nonce/hash as soon as feasible. (2) The audit API calls an LLM provider, framed by SCCs. (3) Our CNDP filing is under review, the receipt will be published upon receipt. Everything is documented in the records of processing.
How can you verify these commitments yourself?
Three ways. (1) Inspect HTTP headers with curl -I on datasouv.ma. (2) Run Mozilla Observatory on the domain, the score is public. (3) Audit the site source code (open under conditions) or consult the public records of processing. If you spot a flaw, write to security@datasouv.ma.
What happens if you find a vulnerability in your own systems?
Response within 72 hours, fix within reasonable time (based on CVSS severity), publication of a post-mortem if the incident has public impact. No legal action against researchers acting in good faith within the published Rules of Engagement. This is the same posture we require from the organisations we support.
Do your clients have access to your detailed posture?
Yes. Under NDA, we share the detailed architecture, internal policies, processor contracts, and the exhaustive list of deployed headers. It is a trust signal and a benchmarking tool for clients calibrating their own level.
Found a vulnerability? Write to security@datasouv.ma
Safe harbor for good-faith researchers, acknowledgement within 72 hours, public post-mortem if impact warrants it. This is exactly the posture we require from the clients we support.