What is the difference between a Lua plugin and a Proxy-Wasm filter in a gateway architecture?

A Lua plugin runs in the gateway’s native Lua environment and is tightly integrated with the platform’s request lifecycle. A Proxy-Wasm filter is a WebAssembly module loaded through the proxy’s Wasm support and executed through the Proxy-Wasm ABI. Both can coexist, but they differ in runtime, portability, and where they sit in the extension stack.

How a Lua Plugin Differs From a Proxy-Wasm Filter in a Gateway

The key difference is execution model. A Lua plugin uses the gateway’s built-in scripting runtime, so it is usually the more direct way to extend request handling inside that platform. A Proxy-Wasm filter is compiled to WebAssembly and loaded through the proxy’s Wasm interface, which makes it more portable across supported runtimes and more constrained in how it interacts with the host.

Runtime, portability, and extension boundaries

A Lua plugin is tied to the gateway implementation that embeds Lua, so its behaviour and available APIs are shaped by that product’s request pipeline. That often makes it faster to develop and easier to fit into the platform’s native extension model, but it also couples the logic more tightly to that gateway.

A Proxy-Wasm filter sits one layer lower in the sense that it targets the Proxy-Wasm ABI rather than a single vendor’s scripting surface. That usually matters when teams want a filter that can move across compatible proxies with fewer changes, or when they want a clearer boundary between custom logic and the host process. For gateway teams, the trade-off is portability versus direct access to platform-specific features.

In practical terms, this means a Lua plugin is often chosen for platform-specific request/response shaping, while Proxy-Wasm is chosen when the same control logic needs to travel with the workload or be shared across environments. The difference is not just syntax, it is where the extension lives in the stack and how much of the host it can assume.

Capability differences that affect implementation

The two approaches also differ in what they make easy or difficult. Lua plugins are typically used where the gateway exposes a ready-made hook into routing, header mutation, authentication-adjacent checks, or policy enforcement. Proxy-Wasm filters are designed around a stricter interface, so they can be safer to reason about in multi-platform estates, but they may require more deliberate design for state handling, performance, and host interaction.

That difference shows up in maintenance. A Lua plugin can be convenient when the gateway is the only deployment target and the team wants rapid iteration. A Proxy-Wasm filter is usually a better fit when the organisation expects to reuse the same control in multiple proxy products, or when it wants a more standardised path for custom traffic logic.

For teams comparing them, the main question is whether the extension is intended to be gateway-native or runtime-portable. If the answer is gateway-native, Lua often wins on simplicity. If the answer is portability and consistent behaviour across compatible proxies, Proxy-Wasm is usually the stronger choice.

How to choose between them in a gateway architecture

The choice depends on operational intent more than on feature labels. If the logic is tightly coupled to one gateway’s lifecycle and configuration model, a Lua plugin fits naturally. If the logic should be distributed as a reusable binary module with a more constrained interface, Proxy-Wasm is the cleaner architectural boundary.

That is why teams should compare not only performance and developer familiarity, but also deployment model, support matrix, and long-term portability. A plugin that is easy to write but hard to move can create lock-in. A filter that is portable but awkward to integrate can slow down delivery. The right choice is the one that matches the expected lifecycle of the control, not just the first implementation.

Risk and Threat Considerations

Extension mechanisms expand the trust boundary of a gateway. A poorly governed plugin or filter can alter routing, mutate headers, inspect sensitive traffic, or create unexpected failure modes, so the main risk is not the language itself but the amount of authority the extension receives inside the proxy path.

Failure mechanism: Overly permissive extension code, weak review, or inconsistent deployment hygiene can turn a small traffic rule into a broad control plane dependency, increasing the blast radius of mistakes or malicious changes.

Impact: Misbehaviour in the extension layer can cause request corruption, policy bypass, traffic interception, or availability issues across every service that depends on the gateway.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA-05 — Least Privilege	Gateway extensions need bounded authority over request handling.
Recommendation — Limit plugin and filter permissions to the minimum needed for their request-phase duties.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	Gateway extension logic directly processes untrusted request data.
Recommendation — Validate all request inputs before a plugin or filter acts on them.
ISO/IEC 27001:2022	A.8.9 — Configuration management	Gateway extension deployment and runtime choice are configuration-sensitive.
Recommendation — Control gateway extension configuration and versioning before enabling production traffic.
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Plugins and Wasm filters depend on hardened gateway configuration.
Recommendation — Harden gateway extension settings and remove unused capabilities.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	Gateway extensions can become the attack surface on exposed proxies.
Recommendation — Hunt for exploit attempts against exposed gateway extension surfaces.

Practitioner Guidance

What to verify: Confirm exactly which host APIs, request phases, and data paths the extension can touch before you approve it for production. If the control depends on gateway-specific behaviour, document that dependency explicitly so the team does not assume it is portable when it is not.

Decision rule: Use the native plugin model when the logic is intentionally platform-specific and tightly coupled to that gateway’s lifecycle; use Proxy-Wasm when you need a portable extension boundary and want to minimise future rewrite risk.

Practitioner takeaway: The important choice is not “Lua or Wasm” in the abstract, it is whether you want a gateway-native hook or a reusable control surface with stricter portability and containment.