Reporting a vulnerability
If you have found a security issue in this site or in any Devzent product, email security@devzent.com. Include enough detail to reproduce it. We acknowledge every report within one business day and aim to have a fix or a mitigation plan within seven days for anything high severity.
We will not pursue legal action against researchers who act in good faith: test only against your own accounts, do not access or modify other people's data, do not degrade service, and give us reasonable time to fix the issue before publishing.
How we build
Security is structural in everything we ship, not a review at the end:
- Every input passes through a validation object with explicit types, lengths and allowed values. No request data reaches a model unvalidated.
- All database access is parameterised. Raw SQL is prohibited outside reviewed migrations.
- Output escaping is on by default; the single place we render HTML is a reviewed component fed only by server-side sanitised content.
- Authorisation is enforced by per-model policies and permission middleware, checked on the server regardless of what the interface shows.
- Rate limits are applied per intent — login, password reset, form submission and file upload each have their own budget.
- Every privileged action writes an immutable audit record with actor, IP, and before/after values.
- Two-factor authentication is mandatory for all administrative accounts.
How we operate
- TLS 1.2+ everywhere, HSTS with preload, a strict Content-Security-Policy with per-request nonces.
- Encryption at rest for databases and backups, with backup encryption keys held separately.
- Dependency scanning on every commit; container image scanning on every build. High and critical findings block the pipeline.
- Automated backups with point-in-time recovery, and restore rehearsals every quarter — an untested backup is not a backup.
- Access to production requires two-factor authentication and is logged. Access is reviewed quarterly.
- Annual third-party penetration testing, with findings tracked to closure.
What we ask of clients
The most common cause of a breach in systems we hand over is not the software. It is a shared admin password, an ex-employee's account left active, or two-factor authentication turned off because it was inconvenient. We set up role-based access properly at handover and we will keep saying this: review your access list quarterly, and never share credentials.
Standards
Our practices are aligned to the OWASP Top 10 and OWASP ASVS Level 2. The full internal checklist — 80+ items with the file or setting that implements each one — is available to clients under NDA on request.