Security built in, and described preciselySecurity built in, and described precisely

How we build

Security decisions belong in architecture and implementation, not in a review at the end. On delivery engagements the following are defaults rather than options.

• Authorisation at the server boundary. Every request is authorised on the server, for the specific resource being acted on. Interface-level hiding of controls is a usability feature, never an access control.
• Input validated against an explicit schema at the edge of the system, with output encoded for the context it is rendered into. Untrusted input never reaches domain logic unparsed and never reaches a query, a shell or a header unescaped.
• Least privilege for service identities, database accounts and cloud roles. A component that only reads gets a role that only reads.
• Secrets in a managed store, such as Azure Key Vault, AWS Secrets Manager or the platform’s environment configuration, and never in a repository, a build artefact or a log.
• Encrypted transport everywhere, with modern TLS, and encryption at rest through the platform’s managed capabilities.
• Dependency hygiene. Locked dependency versions, automated vulnerability alerting, and upgrades assessed on the actual exposure rather than applied blindly.
• Logging and monitoring sufficient to reconstruct what happened, with credentials, tokens and personal data redacted at the logging boundary rather than by convention.
• Rate limiting and abuse controls on public endpoints, sized to the endpoint rather than applied uniformly.

We design and implement identity and access architecture with Entra ID, Okta, SAML 2.0, OAuth 2.0 and OpenID Connect. Where an engagement requires formal penetration testing, we build to pass it and work alongside the specialist firm that performs it.

How this website is operated

The site is a statically generated Next.js application deployed to Cloudflare Workers. The controls applied to it are the ones we would apply to client work at the same risk level.

• HTTPS only in production, with HSTS.
• A Content-Security-Policy that allows scripts from this site and, only after consent, Google Analytics, no unsafe-eval, object-src ‘none’, base-uri ‘none’ and form-action ‘self’.
• Clickjacking prevented through frame-ancestors ‘none’.
• X-Content-Type-Options: nosniff, a restrictive Referrer-Policy and a Permissions-Policy disabling device APIs the site has no use for.
• Fonts are self-hosted and the only third-party script, Google Analytics, loads only after a visitor accepts it, so no request reaches another party without their choice.
• The contact endpoint validates server-side, limits request size, rate limits by client address, checks request origin and rejects anything that fails, returning a generic message rather than a diagnostic.
• Preview deployments are excluded from indexing.

Reporting a vulnerability

If you believe you have found a security problem in this site or in something we built, please tell us before telling anyone else. Email hello@codentures.eu with enough detail to reproduce the issue. We will acknowledge receipt, keep you updated, and we will not pursue anyone who reports in good faith and does not access or modify data belonging to others.

A machine-readable contact is published at /.well-known/security.txt.

Certifications and compliance

We build systems designed to support our clients’ compliance obligations, including GDPR, and we answer procurement and security questionnaires accurately. We do not describe a client system as certified against a standard on the client’s behalf; where evidenced compliance such as ISO 27001 or SOC 2 is required, we work alongside the auditor and help you scope it.

How security is handled on a specific engagement is part of the delivery quality standard.