Kong Open Source
You set up kong open source by defining upstream services, routes, and plugins. This open source tool sits in front of your web apps and routes client traffic. Engineering teams use it to manage public APIs from one central point. A client sends a web request, and the tool forwards it to the right app. Teams often start by setting broad rules to get traffic flowing fast. When permissions stay too broad, any caller with a valid key can reach internal routes. Over time, shared keys and wide netwo
Snyk Open Source + Kong Security Plugins: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up kong open source by defining upstream services, routes, and plugins. This open source tool sits in front of your web apps and routes client traffic.
Engineering teams use it to manage public APIs from one central point. A client sends a web request, and the tool forwards it to the right app. Teams often start by setting broad rules to get traffic flowing fast. When permissions stay too broad, any caller with a valid key can reach internal routes. Over time, shared keys and wide network paths create big security risks for backend data.
How kong open source routes traffic and checks rules
At its core, kong open source runs on top of a fast web engine. It listens for incoming web calls and matches them against your defined routes. Each route points to an upstream service, such as a billing app or user API. You can run the tool with a database or use a flat file for rules.
In database mode, you update routes and plugins through an admin API. The tool stores these settings in a central store and shares them across nodes. In declarative mode, you load one flat file into memory on each node. Both setups let you add plugins to check keys, limit call rates, and log requests.
Plugins run at specific steps during the life of a web call. When a request arrives, an auth plugin checks the caller's token or API key. Next, a rate limit plugin counts how many calls that user sent in the last minute. If the call passes every check, the node sends it to the backend app.
What native API routing solves and what it misses
This native setup solves major problems for public web traffic and service-to-service calls. It stops bad requests at the edge before they hit your core apps. You get one place to manage TLS certs, rate limits, and basic key checks. App developers do not need to write rate limit code inside every single microservice.
Still, an API router only governs web traffic between apps and external clients. It does not manage how engineers run live commands against databases, cloud consoles, or servers. When a developer needs to fix a bug, they bypass the API router completely. They log in directly to the database or server using a local client tool.
Snyk Open Source + Kong Security Plugins: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Native API rules also decide who gets in, not what happens inside a session. Even for internal admin APIs, a valid key grants full access to that route. The open source version lacks fine-grained role checks and built-in data masking for results. If a response holds emails, phone numbers, or card numbers, the caller gets everything.
How to tighten rules for internal admin routes
To keep internal routes safe, split your public APIs from your admin endpoints. Never expose the admin API on public network ports. Bind the admin listener to a local address or a locked-down private network. Require strong tokens for anyone who changes routes or plugin settings.
Group your routes by sensitivity and apply strict plugins to high-risk paths. Use consumer groups to limit which keys can call specific backend services. Review your active keys often and delete old credentials that teams no longer use. For direct engineer sessions to backend data stores, pair your API edge with dedicated session controls.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Can kong open source run without a database?
Yes, you can run it in a declarative mode without an external database. You define all services, routes, and plugins in one static file and load it into memory.
What is the difference between a service and a route?
A service represents your backend app or upstream API that receives traffic. A route defines the public path or host rules that match incoming client calls to that service.
Does kong open source control direct database queries from engineers?
No, it is built to route web and API traffic between clients and apps. It does not inspect SQL queries or mask fields like emails and card numbers in database results.