Security updates and advisories
Voir tous les tags
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.
STOA runs 9 parallel security jobs on every pull request — secret scanning, SAST for three languages, dependency audits, container scanning, license compliance, SBOM generation, and commit signature verification. This article breaks down each job, explains what it catches, and shows you how to adopt the same approach in your own projects. This is part of our open-source API gateway philosophy: security scanning should be built into CI, not bolted on after a breach.
Running an API gateway in production requires more than deploying with default settings. An insecure gateway exposes every backend service to attack, leaks sensitive data, and creates compliance nightmares. This 10-step security hardening checklist covers the critical controls you need before production deployment. Each step includes concrete configuration examples and verification commands.
AI agents need programmatic API access, but traditional authentication patterns designed for human users — browser cookies, session tokens, OAuth2 authorization code flows — don't work. AI agents are autonomous services, not users. They operate without browsers, without human-in-the-loop interactions, and at machine speed. This article presents five authentication patterns that work for AI agents, from the simplest (API keys) to the most secure (mTLS certificate binding), with practical implementation examples for each.
This is part of the What is an MCP Gateway series. For the broader context on why AI agents need specialized infrastructure, see Connecting AI Agents to Enterprise APIs.
10 practical security steps that take less than a day and prevent 95% of API incidents. No enterprise budget, no complex tooling — just engineering discipline. Covers secrets, rate limiting, CORS, auth, TLS, logging, and dependency management.
You're a freelancer. You shipped an API for a client. It works. Tests pass. Invoice sent.
Six months later, the client calls: someone scraped their entire user database through your API. No rate limiting. No input validation. Default CORS headers. The API key was in the frontend JavaScript.
This happens more often than anyone admits. And it's almost always preventable with a simple checklist. This is part of our open-source API management philosophy: security should be accessible to everyone, not just enterprises.
Deleted API keys stay in git history forever. This article shows you how to detect leaked secrets with gitleaks, remove them from history, and prevent future leaks with pre-commit hooks and proper secret management.
You removed the hardcoded API key from your code. You committed the fix. You pushed. You're safe now, right?
No. The key is still in your git history. Anyone with git log -p can find it in seconds.
This isn't a theoretical risk. GitHub scans over 100 million commits per day and finds thousands of valid secrets — API keys, database passwords, cloud credentials. Most of them were "removed" by developers who thought deleting the line was enough.
This is one of the most critical security gaps in modern API development — and one of the reasons we built STOA as an open-source API gateway with secrets management as a default, not an add-on.