Secure a regulated-data API by modeling who could misuse it, checking authorization on every object and field, collecting and returning as little data as possible, and keeping secrets and audit logs under strict control. The weaknesses that matter most in practice are gaps in authorization and responses that expose too much data, not broken encryption.
Start with a threat model for the data, not the framework
Before choosing tools, write down what the API exposes and who could misuse it. For a bank that means account and transaction data; for an energy or utility company it can mean metering data, customer contracts and operational readings from the network.
A useful threat model is short. It lists the sensitive data, every caller that can reach it, the actions each caller should be able to take, and what happens if one of them is compromised. That document then drives every control below, and it tells reviewers what to test.
- Which data is personal, confidential or regulated, and where it is stored.
- Every consumer of the API: internal services, partners, mobile apps and administrators.
- What each consumer is allowed to read, change or trigger.
- The impact of a leaked token, a malicious insider or a compromised partner system.
Authenticate every caller, then authorize every object
Use a standard protocol such as OAuth 2.0 with OpenID Connect for users, and short-lived tokens or mutual TLS for service-to-service calls. Avoid long-lived shared API keys, because nobody can tell which system used them or revoke them without breaking others.
Authentication only proves who is calling. The first entry in the OWASP API Security Top 10 is broken object level authorization: a valid user changes an identifier in the request and reads someone else's record. Check ownership or tenancy on the server for every object, every function and every sensitive field, and never trust an identifier or a role sent by the client.
Give every client and service the least privilege it needs
Least privilege limits the damage when something does go wrong. Issue separate credentials per consumer, scope tokens to specific operations, and keep administrative endpoints on a separate path with stronger checks.
Apply the same rule below the API. The service account that reads meter data should not be able to delete it, and a reporting job should connect with a read-only database role. Review permissions on a schedule, because access granted for a one-off task tends to stay forever.
Collect less, return less and keep it for less time
Data minimization is both a GDPR principle and a strong security control: data you never store cannot leak. Ask for each field whether the service truly needs it, and drop or pseudonymize what it does not.
Apply the same discipline to responses. Define explicit response schemas instead of serializing whole database objects, mask identifiers such as account numbers where the full value is not needed, and set retention periods so old records are deleted. Document the lawful basis for each processing purpose and sign processor agreements with any vendor that handles the data. This is engineering practice, not legal advice, so involve your data protection officer or counsel for the legal assessment.
Validate every input and limit what one caller can consume
Treat every request as hostile until validated. Enforce a schema for each endpoint, reject unknown fields, and use parameterized queries so input never becomes part of a database command.
Several OWASP API risks come from missing limits rather than bad code. Rate limit per client, cap page sizes and payload sizes, and protect sensitive business flows such as payment or contract changes against automated abuse. If the API fetches remote URLs on behalf of callers, restrict destinations to prevent server-side request forgery.
Keep secrets out of code, images and logs
Database passwords, signing keys and partner credentials belong in a dedicated secrets manager, injected at runtime and rotated on a schedule. Scan repositories and container images for secrets in the build pipeline, and treat any secret that reaches version control as compromised.
Separate secrets per environment so a leaked test credential never opens production. Restrict who can read secrets in production, and log every access to them.
Log for audit and design for fewer incidents
Regulated environments need to answer a simple question after the fact: who accessed which data, when, and through which client. Record that for every sensitive read and write, store logs where application operators cannot alter them, and keep personal data out of log messages.
Pair logging with alerts on unusual patterns, such as one client reading far more records than usual, and a tested incident response plan. Through Sopra Steria, our engineers built secure APIs for sensitive utility data under regulatory constraints and led an operational supervision tool where enforced security standards went together with fewer production incidents. SDK Enterprises applies the same practices to client projects today.
Key takeaways
- A short, written threat model for the data should drive every security control on the API.
- Check authorization on the server for every object, function and sensitive field, not just at login.
- Least privilege applies to tokens, service accounts and database roles alike.
- Data minimization reduces both GDPR exposure and the impact of any breach.
- Audit logs must show who accessed what and when, without leaking personal data themselves.
FAQ
Is HTTPS enough to secure an API?
No. TLS protects data in transit, but many API breaches involve authenticated callers reaching data they should not see. Authorization checks, input validation, rate limits and audit logging are still required.
What is broken object level authorization?
It is a flaw where the API checks that a caller is logged in but not that the requested record belongs to them. Changing an identifier in the URL or body then exposes other users' data. The fix is an ownership or tenancy check on the server for every object.
Does GDPR prescribe specific API security controls?
GDPR requires appropriate technical and organizational measures for the risk involved, without mandating specific tools. Controls such as access restriction, minimization, pseudonymization and logging are common ways to meet that requirement, and your legal advisers should confirm what applies to your case.