When an external-facing system becomes the entry point for unauthorized data access, you're facing a choice that should have been made months earlier: which API appropriate technical and organisational measures to implement, and in what order. CenterPoint Energy recently experienced a breach through an inadequately protected API, highlighting the consequences of deferring this decision.
The threat actor claimed the endpoint lacked authentication, rate limiting, and other basic protections. Whether or not the full scale of the alleged compromise is accurate, the incident raises a question every utility and critical infrastructure operator must answer: which API security measures matter most when you're protecting customer data at scale?
The Decision You're Facing
You manage APIs that expose customer information to legitimate business functions: billing integrations, mobile apps, partner portals, or customer service tools. Each endpoint represents both operational value and exposure risk.
Your choice isn't whether to secure these interfaces. It's which controls to prioritize when resources are finite, technical debt is real, and business teams need those APIs operational tomorrow.
Three factors determine your path:
Data sensitivity. What's actually flowing through the endpoint? Full account details including partial Social Security numbers and payment information demand different controls than service appointment availability.
Access patterns. Is this endpoint queried ten times per day by a known partner system, or hit thousands of times hourly by a mobile app with rotating IP addresses? The threat model changes completely.
Regulatory obligations. Under Article 32 GDPR, you must implement appropriate technical and organizational measures based on the risks presented by your processing. For utility companies processing special category data or operating critical infrastructure, supervisory authorities expect defense in depth, not single-layer protection.
Path A: Authentication and Authorization First
Choose this when: Your API serves known parties (partner systems, internal applications, specific processor integrations) and processes high-sensitivity customer data.
Start with strong authentication. API keys alone don't cut it when you're exposing personal information at scale. Implement OAuth 2.0 or mutual TLS authentication so you know exactly which system is making each request.
Layer on granular authorization. The billing system doesn't need access to service history. The mobile app doesn't need bulk export capabilities. Define scopes that match legitimate business purposes, then enforce them at the API gateway level.
Log every authentication attempt and authorization decision. When a supervisory authority asks how unauthorized access occurred, "we don't have those logs" is not an answer that demonstrates Article 32 compliance.
This path works when you can enumerate your legitimate callers. It fails when you're serving a public-facing mobile app with millions of users, each generating their own authentication tokens.
Path B: Rate Limiting and Input Validation
Choose this when: Your API must remain publicly accessible or serve highly variable traffic patterns, but you need to prevent bulk extraction and automated abuse.
Implement aggressive rate limiting at multiple levels. Per-IP limits catch the simplest scraping attempts. Per-account limits prevent a single compromised credential from exfiltrating your entire customer base. Per-endpoint limits protect specific high-value functions.
The threat actor in the CenterPoint incident allegedly extracted data before the company intervened. Rate limiting wouldn't have prevented the breach, but it would have constrained the scale and bought time for detection.
Validate every input. Reject malformed requests before they reach your application logic. Sanitize parameters that could enable SQL injection or path traversal. Return consistent error messages that don't leak information about your data structure.
Monitor for anomalous patterns. A sudden spike in requests for customer account details, especially outside business hours, deserves immediate investigation. Set thresholds that trigger alerts before the damage scales.
This path buys you time and reduces blast radius. It doesn't prevent a determined attacker with valid credentials from accessing what they're authorized to see.
Path C: Data Minimization and Field-Level Controls
Choose this when: You're redesigning the API or can modify response payloads without breaking existing integrations.
Return only what the caller legitimately needs. If the mobile app displays a customer's name and current balance, don't include their full service history, payment methods, and partial Social Security number in the response.
This isn't just good security architecture. It's a transparency obligation under Articles 13 and 14. You must tell data subjects what personal data you process and for what purposes. If your API returns fields your application doesn't use, you're processing data without a defined purpose.
Implement field-level access controls. The customer service portal might need full account details. The outage notification system needs service addresses but not payment information. Design your API to serve different data sets based on the authenticated caller's role.
Consider tokenization for sensitive identifiers. Instead of returning account numbers or partial Social Security numbers, return opaque tokens that map back to real values only within your secured systems.
This path requires upfront design work and potentially breaking changes to existing integrations. It pays dividends when the next breach occurs and you can demonstrate that the compromised endpoint never had access to your most sensitive data fields.
Summary Matrix
| Control Type | Best For | Implementation Effort | Breach Mitigation | GDPR Article 32 Weight |
|---|---|---|---|---|
| Authentication & Authorization | Known callers, high-sensitivity data | Medium | Prevents unauthorized access entirely | High |
| Rate Limiting & Monitoring | Public endpoints, variable traffic | Low to Medium | Constrains blast radius, enables detection | Medium |
| Data Minimization & Field Controls | Redesigns, long-term architecture | High | Limits exposure per successful attack | High |
You don't choose just one path. CenterPoint's incident demonstrates what happens when you choose none of them adequately.
Start with authentication for any endpoint that returns personal data. Add rate limiting to everything. Then work backward through your API inventory, asking which fields each endpoint truly needs to return.
When the next SEC filing describes unauthorized access through your external-facing systems, the question won't be whether you had appropriate technical and organisational measures. It'll be whether you implemented the right ones, in the right order, before the breach occurred.
