Security updates and advisories
View All Tags
Three weeks after launch, a client emails: "Our data looks wrong. Something happened last Tuesday at 3am."
You have two possible answers:
This is Part 3. We'll build the audit capability that lets you answer the first way.
You set up rate limiting: 100 requests per minute. Done, right?
Not quite. A fixed limit of 100 req/min breaks legitimate users during burst activity, lets bots abuse you with slow trickle attacks, and doesn't differentiate between your free users and your paying customers.
This is Part 2 of the series. We'll go deep on rate limiting — the strategies that work in practice.
You've deployed your API. Maybe it's a side project, maybe it's client work, maybe it's the backend for a SaaS you're building on evenings and weekends.
Here's what's probably happening to it right now — without you knowing.
Zero Trust architecture assumes breach — if you assume attackers are already inside, your priority shifts from pure prevention to detection. STOA generates structured audit events and Prometheus metrics that enable detection of credential abuse, prompt injection attempts, rate abuse, and data exfiltration patterns. This article covers what STOA detects, how to query for attack signals, and a practical incident response playbook.
Most "Hello World" tutorials get you to a running endpoint. This one gets you to a protected endpoint — with rate limiting, authentication, and an audit trail — because that's what production actually requires.
This is the freelancer edition: opinionated, fast, and realistic about what breaks first when you launch.
This checklist implements Zero Trust architecture with STOA Platform in 10 actionable steps. Each step is independently deployable and verifiable. Start from the top — steps 1-3 provide the most immediate security improvement and can be implemented in under an hour.
Zero Trust for API gateways means one thing: never trust, always verify — every request, regardless of network origin, must present verifiable identity and be evaluated against explicit policy before receiving access. This article explains the five Zero Trust principles and how they apply specifically to API gateway design, with concrete examples from STOA Platform's implementation.
The OWASP API Security Top 10 (2023) lists the most critical API security risks. An API gateway like STOA helps address several of these at the infrastructure layer — but not all of them. This article maps each OWASP risk to STOA's controls, with an honest assessment of what requires application-level implementation.
STOA Platform secures AI agent API access through five independent layers: mTLS certificate binding, OAuth 2.1 with PKCE, OPA policy evaluation, AI guardrails, and immutable audit logging. Each layer addresses a distinct threat class. Compromise of any single layer does not grant unauthorized access. This article describes the security architecture, threat model, and design rationale for each layer.
MCP clients like Claude Desktop and GPT are public clients. They cannot store client secrets. OAuth 2.1 with PKCE (Proof Key for Code Exchange) solves this by replacing the client secret with a cryptographic proof that only the original requester could produce. This article walks through the complete OAuth flow for MCP gateways, including the discovery chain, dynamic client registration, and the production pitfalls we encountered and solved.