The Kong Plugin Development Kit is the set of functions and variables plugins use to interact with requests, responses, and stream connections. It provides the interface for implementing custom logic inside the gateway lifecycle, including access to request data, routing context, and other plugin-level behaviors.
What the Kong Plugin Development Kit Does
The Kong plugin development kit is the runtime interface that lets plugins inspect and influence gateway traffic as requests and responses move through the Kong lifecycle. It exposes the contextual hooks custom logic needs to read metadata, make routing decisions, and participate in stream handling.
That makes the PDK less like a standalone product feature and more like the contract between gateway internals and plugin code. If you understand the PDK, you understand where a plugin can observe traffic, where it can modify behavior, and where it must remain careful about performance, trust boundaries, and data handling.
How Plugins Use the PDK in the Gateway Lifecycle
Plugins rely on the PDK to run at specific phases of request processing, such as access, header transformation, response handling, or stream events. Those phases matter because the same function can have different consequences depending on when it executes, what context is available, and whether the plugin is acting before or after upstream routing.
The key practical idea is that the PDK exposes gateway state, not unrestricted system access. A plugin can often read request details, route context, consumer context, or downstream metadata, but only within the constraints of the phase and execution environment. That separation is what makes custom behavior possible without turning every plugin into a full gateway override.
Security Implications of Plugin-Level Control
Because plugin code executes inside the request path, it can affect authentication, authorization, logging, header manipulation, request enrichment, and other control points that influence security posture. A plugin that misuses request context can leak data, alter trust decisions, or create inconsistent behavior across routes and services.
In practice, the PDK becomes security-sensitive whenever a plugin touches secrets, tokens, headers, identity claims, or upstream destinations. That does not make the kit inherently unsafe, but it does mean plugin authors are operating in a privileged part of the traffic flow where small mistakes can have gateway-wide impact.
For a broader view of gateway and API exposure patterns, see the OWASP API Security Top 10 and the control lens in NIST SP 800-53 Rev 5 Security and Privacy Controls.
Extending Kong Safely with Custom Plugin Logic
Custom plugins are most valuable when they express a narrowly defined gateway behavior, such as request tagging, tenant-aware routing, protocol normalization, or policy checks. The PDK gives developers the building blocks, but the implementation still has to respect latency, error handling, and phase ordering or the plugin can degrade the gateway experience.
The safest mental model is to treat the PDK as an execution surface with bounded authority. Good plugin design keeps logic deterministic, avoids unnecessary state, and uses the smallest set of request and response fields needed to produce the desired outcome.
For implementation patterns around secure software delivery and gateway-adjacent code quality, OWASP SAMM and SLSA are useful complements when the plugin is built and deployed as part of a broader supply chain.
Risk and Threat Considerations
Plugins that use the PDK sit close to request flow, so failures are often high impact: a bad assumption about context, a malformed header, or overly broad access to request data can create security gaps across every request that matches the plugin. The risk is not only malicious code, but also trusted custom code behaving incorrectly under load or edge-case traffic.
Failure mechanism: A plugin can expose sensitive data, weaken routing or authorization decisions, or create a supply-chain entry point if unreviewed code is deployed into the gateway.
Impact: Compromise or misbehavior at this layer can affect confidentiality, integrity, and availability for multiple services at once, because the gateway is a shared enforcement point.
Where the concern is plugin provenance and runtime abuse, the threat model overlaps with MITRE ATT&CK Enterprise Matrix for execution and credential abuse patterns, and with NIST AI Risk Management Framework only when plugin logic is part of a larger AI-enabled workflow that changes trust decisions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP SAMM and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Plugin code can alter gateway behavior and enforce or bypass function-level decisions. |
| Recommendation — Constrain plugin actions to the minimum functions the gateway extension truly needs. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Plugins operate with privileged request-path access and should be limited accordingly. |
| SI-7 — Software, Firmware, and Information Integrity | Custom plugin code must be protected against tampering and untrusted deployment. | |
| Recommendation — Limit plugin privileges to the smallest set of traffic context and actions required. Verify plugin integrity before deployment and reject altered or untrusted builds. | ||
| OWASP SAMM | Implementation — Implementation | Custom plugin development is a software-building activity that needs secure engineering practice. |
| Recommendation — Build plugin logic with secure coding, review, and release controls. | ||
| SLSA | Level 3 — Build provenance and integrity | Gateway plugins are supply-chain artifacts whose provenance affects runtime trust. |
| Recommendation — Require proven build provenance for plugin artifacts before they reach production. | ||
Practitioner Guidance
Governance implication: Treat plugin development as a privileged gateway extension, not as ordinary application code. Ownership should be explicit, because the PDK gives authors access to live traffic context and any mistake can become a shared control failure.
What to watch for: Review whether a plugin actually needs the request, response, or stream fields it consumes, and whether it changes behavior at the correct phase. If a plugin starts accumulating special cases, hidden dependencies, or side effects, its operational risk is usually rising faster than its utility.
Practitioner takeaway: The PDK is powerful precisely because it is close to enforcement, so the right design discipline is restraint, not cleverness.
Related resources from NHI Mgmt Group
- Plugin Development Kit
- What are the signs that a checkout flow has been hijacked by a malicious plugin or phishing kit?
- What is the difference between CloudFormation and the AWS Cloud Development Kit for deploying hybrid infrastructure?
- How should teams debug unexpected Kong Gateway behavior before changing routing or plugin settings?
