What is the difference between the request and response phases when building gateway plugins?

The request phase runs before traffic is sent upstream, so it is used for decisions like authentication, transformation, and routing control. The response phase runs after the upstream service replies, so it is suited to headers, response shaping, and monitoring logic. Choosing the right phase keeps behavior aligned with the traffic lifecycle and avoids unnecessary processing.

Request phase: what it does in a gateway plugin

The request phase is the pre-upstream control point, so it is where a plugin can inspect, normalise, allow, block, or rewrite traffic before the gateway forwards it. That makes it the right place for decisions that should happen once, early, and consistently, especially when the downstream service should never see unauthenticated or malformed traffic.

Because this phase sits on the ingress side of the transaction, it is also where plugin authors usually place request-scoped transformations such as header edits, query validation, tenant selection, path rewrites, and policy checks. If a decision changes whether the request should proceed at all, the request phase is usually the correct place to make it.

In practice, the request phase is the strongest fit for controls that must influence routing or access before any backend cost is incurred. For example, if a gateway plugin needs to enforce an auth decision, derive an upstream target, or attach request metadata for later handling, doing that work early reduces avoidable load and keeps the request lifecycle predictable.

Response phase: where post-upstream handling belongs

The response phase starts after the upstream service has already processed the request and returned a result, so the plugin is now shaping the reply rather than deciding whether the call may continue. That makes it suitable for response headers, body filtering, status translation, observability tags, and final logging that depends on the upstream outcome.

Because the upstream application has already done its work, response-phase logic should focus on what the client receives and what the platform learns from the exchange. It is the natural place for payload shaping, cache-related headers, tracing enrichment, and monitoring logic that benefits from knowing the outcome of the upstream call.

The main operational difference is timing. Request-phase logic can stop or modify traffic before cost is spent upstream, while response-phase logic can only react to what has already happened. That distinction matters when a plugin may need to enforce policy, trim sensitive output, or record completion signals without changing the upstream decision itself.

Choosing the phase that matches the traffic lifecycle

The right choice depends on whether the plugin needs to influence admission or observe outcome. If the plugin must make an access, transformation, or routing decision, the request phase is the better fit. If it must adapt, redact, or record the result after the upstream call, the response phase is the correct fit. Mixing those responsibilities usually creates brittle plugins that are harder to reason about and harder to test.

When gateway logic crosses into API security concerns, phase choice also affects how much exposure exists before a control can act. The same lifecycle logic is why response-side filtering cannot replace request-side validation, and why request-side blocking cannot inspect data that only exists after upstream execution.

For teams building extensible gateways, the phase boundary is also a design boundary. It helps separate policy enforcement from outcome handling, which keeps plugins easier to compose and reduces accidental duplication of work across multiple filters or hooks.

Risk and Threat Considerations

Phase confusion is a common failure mode: if a control is placed in the response phase when it needed to run before upstream forwarding, the gateway may already have exposed backend capacity, accepted invalid input, or allowed a request that should have been stopped. The reverse mistake can cause a plugin to overreach into response handling and miss the context it needed to make a safe upstream decision.

Failure mechanism: A plugin that depends on response-phase execution for admission control, request sanitisation, or route selection cannot prevent the upstream call from happening, so the wrong phase creates avoidable exposure and inconsistent behaviour.

Impact: The practical result is weaker enforcement, wasted backend work, and harder incident analysis because the plugin no longer aligns with the traffic event it was supposed to govern.

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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP API Security Top 10	API8 — Security Misconfiguration	Gateway phase misuse can create API exposure and control gaps.
Recommendation — Place policy checks in the correct gateway phase to prevent exposed API flows.
NIST SP 800-53 Rev 5	AC-3 — Access Enforcement	Request-phase logic often enforces who may proceed upstream.
	AU-2 — Event Logging	Response-phase handling often records outcome-dependent telemetry.
Recommendation — Enforce access decisions before forwarding requests to upstream services. Capture outcome-aware gateway events after the upstream response returns.
CIS Controls v8	CIS-16 — Application Software Security	Plugin phase selection is part of secure application design and control placement.
Recommendation — Design plugin hooks so enforcement and response handling occur in the correct lifecycle stage.

Practitioner Guidance

What to verify: Confirm whether the plugin must decide before forwarding, after the upstream reply, or in both places. If the answer is “before,” keep the logic in the request phase even if the same data is later useful for logging or shaping.

Decision rule: Put any control that changes whether the upstream request happens in the request phase, and put any control that changes what the client sees after the upstream reply in the response phase. If a rule needs both, split it into two smaller functions rather than forcing one phase to do both jobs.

Practitioner takeaway: The best gateway plugins respect the traffic lifecycle, because phase discipline is what keeps enforcement early, response handling late, and the system understandable under load.