Security Engineering
API Security (DIY)
A four-week DIY API security POC — discovery, enforcement, and telemetry across Azure API Center, F5, CrowdStrike, Azure Functions, and Postgres — now in Phase 2 production planning.
Overview
Vendor API security tools often leave gaps between inventory, runtime enforcement, and detection. This project was a four-week DIY proof of concept to build a tailored API security control plane for a client — then prove it could move into a production build.
The POC is complete. We are now in Phase 2 planning: turning the validated design into an operable production system.
The Problem
APIs multiply across cloud gateways, internal services, and partner integrations. Without a coherent control plane, teams struggle to answer basic questions: what APIs exist, who can call them, what policy applies at the edge, and which signals mean real risk versus noise.
Off-the-shelf products covered pieces of that story. They did not fit the client’s existing F5, CrowdStrike, and Azure footprint tightly enough to become the daily source of truth. The DIY approach was chosen to meet the stack where it already lived.
What We Built
Inventory and policy context
Azure API Center provided a structured inventory of APIs and ownership metadata. The POC used that catalog as the spine for discovery and for tying policies back to real services — not anonymous endpoints.
Edge enforcement
F5 sat in the enforcement path so traffic policy and API awareness could meet at the edge. The goal was actionable control: allow, challenge, or block based on what the inventory and risk signals said — not a detached scan report.
Detection and telemetry
CrowdStrike supplied endpoint and identity-adjacent signals that correlated with API abuse patterns. Custom Python and Go services, with Azure Functions for event-driven glue, normalized those signals and wrote durable state into Postgres.
Shared evidence
Findings and inventory snapshots landed in a database the security and platform teams could query together. That shared trail mattered as much as any single integration: it turned the POC into something stakeholders could validate before committing to production.
Approach
- Scope the POC — Pick a representative set of APIs, gateways, and detection sources that exercise the full path without boiling the ocean.
- Wire the control plane — Connect Azure API Center, F5, CrowdStrike, Functions, and Postgres into one coherent flow.
- Validate with operators — Confirm inventory accuracy, enforcement behavior, and that alerts were usable — not just technically possible.
- Plan Phase 2 — Capture production requirements: reliability, scale, ownership, and hardening beyond the four-week spike.
Who It Is For
Security and platform teams that need API security aligned to their existing gateway and detection stack, and that are willing to invest in a purpose-built control plane when vendor products leave too much unfinished.
Current Status
POC complete. Phase 2 production planning is underway — refining architecture, operational ownership, and the path from validated prototype to a system the client can run day to day.
Interested in a similar engagement? Get in touch.
- Discovery and enforcement. Mapped APIs through Azure API Center and wired enforcement at the edge with F5, so inventory and policy stayed connected instead of living in separate spreadsheets.
- Integrations that fit the stack. Python and Go services plus Azure Functions pulled signals from CrowdStrike and persisted findings in Postgres — giving security and platform teams a shared evidence trail.
- POC to Phase 2. The four-week proof of concept validated the architecture; Phase 2 planning now hardens it for production operations, scale, and ownership.