Skip to main content
Codexway

Application security

Application security and API protection

I secure your applications where it actually matters: identities, authorisations, secrets and input validation. The measures are verifiable and integrated into the delivery pipeline.

Request a quoteGet in touch

What it covers

Application security rarely fails because of weak cryptography. It fails on inconsistent access control, secrets shared in configuration files, unvalidated input, and logging too thin to reconstruct an incident.

We start by modelling actors and resources: who may do what, on which data, in which context. That model becomes the single reference, implemented server-side and verified by automated tests. Any access rule that is not tested is treated as unreliable.

Security wired into delivery

Dependency checks, security-oriented static analysis and authorisation tests run on every delivery. Secrets are removed from repositories and handled by a vault, with rotation and access logging.

  • Authorisation model documented and tested per resource.
  • Delegated authentication with short-lived tokens and session rotation.
  • Centralised secrets, never committed.
  • Systematic validation of input and file uploads.
  • Audit logging usable during an incident.

Problems addressed

  • Access rules are scattered and sometimes contradictory.
  • Production credentials sit in configuration files.
  • No test verifies that a user without rights is actually refused.
  • Outdated libraries are not tracked between audits.
  • During an incident, logs cannot reconstruct who accessed what.

Expected benefits

  • An authorisation model that is understandable and verifiable.
  • Secrets out of code repositories, with rotation.
  • Vulnerabilities detected before production release.
  • Audit trails that let you reconstruct an incident.
  • Argued answers to auditor questions.
  • Security that does not slow delivery down.

Method and steps

  1. 1

    Access modelling

    Cataloguing actors, resources and permitted operations in a single document used as the reference for development and testing.

  2. 2

    Technical hardening

    Introducing delegated authentication, short-lived tokens, session rotation, centralised secrets and input validation.

  3. 3

    Automated testing

    Writing tests that check refusals as much as permissions, and adding dependency checks and static analysis to the delivery pipeline.

  4. 4

    Review and remediation

    Reviewing results, fixing gaps in order of risk, adding audit logging and documenting incident procedures.

Deliverables

  • Documented, versioned authorisation model.

  • Authentication and session management configuration.

  • Automated positive and negative access control tests.

  • Secret management policy and rotation procedure.

  • Dependency vulnerability report with remediation plan.

  • Security incident response procedure.

Technologies used

  • Spring Boot
  • Spring Security
  • PostgreSQL
  • Kubernetes
  • Keycloak
  • OAuth 2.1 et OpenID Connect
  • HashiCorp Vault

Frequently asked questions

Do you perform penetration tests?

I run in-depth technical reviews and automated authorisation tests. For a formal penetration test with a defensible report, I work with a specialised partner and align with your compliance requirements.

Do we need an external identity provider?

With several applications or a single sign-on requirement, a standard identity provider clearly simplifies account management, roles and offboarding.

How do you handle detected vulnerabilities?

Each vulnerability is assessed for real exploitability in your context, then classified as immediate fix, planned fix, or a risk explicitly accepted in writing.

Related case studies

Request a security review

Tell me about your regulatory context and application scope. I will propose an approach proportionate to the real risk.

Request a security review