Secure by Construction

What this means in practice

Build security into the API contract and implementation from the start, rather than relying on reviews and patching later.

Every endpoint should assume a hostile environment and enforce least privilege by default.

Access is scoped, sensitive data is explicitly classified, and abuse protections are built into the interface so that safe operation is the default behaviour.

Why this matters

APIs are exposed surfaces and are routinely probed, misused, and automated against. When security is designed in, teams reduce the likelihood and impact of breaches, prevent accidental data exposure, and avoid expensive retrofits late in delivery. Secure defaults also make it easier to build consistent, auditable systems that meet regulatory and client expectations.

Practices that meet this principle

• Control who can do what by using clear permission levels for each action (Roles based security)

• Only give customers and internal services the minimum access they need to do their job

• Apply rate limiting, throttling, and abuse detection at appropriate boundaries

• Classify sensitive fields, and enforce handling rules (for example: redaction in logs, encryption at rest, access constraints)

• Assume untrusted clients and networks (for example: input validation, authentication on every request, no implicit trust)

• Securely test each endpoint (for example: auth tests, negative tests, common OWASP API risks)

Validation

A project meets this principle when:

• Access control is explicit, scoped, and least-privilege by default

• Sensitive fields are identified and protected, and do not leak via responses or logs

• Abuse protections exist and are monitored (rate limits, throttles, anomaly detection)

• Security testing covers each endpoint, including authorisation and misuse scenarios

• The API remains secure under hostile assumptions, not just happy-path usage