Ingest endpoint accepts unverified events via NoopVerifier fallback

[sulthonzh]

Description

The ingest endpoint (/ingest/{maskID}) falls back to a NoopVerifier when a source has no matching verifier type configured. This means any HTTP source with an empty or unrecognized verifier type will accept all incoming requests without any authentication or signature verification.

Context

• File: api/ingest.go:87-93
• Component: Ingest event handler / Source verification

Current Behavior

When verifierConfig.Type does not match any known verifier (HMacVerifier, BasicAuthVerifier, APIKeyVerifier), the code silently falls back to a no-op verifier:

default:
    v = &verifier.NoopVerifier{}

This means:

1. If a source is created without specifying a verifier type (empty string), all incoming events are accepted unverified
2. If a new verifier type is introduced but a source has a stale config, events bypass verification
3. There is no logging or warning when the NoopVerifier is used, making it invisible to operators

For a webhook gateway where verifying the authenticity of incoming events is a core security feature, silently accepting unverified events is a significant risk.

Expected Behavior

The ingest endpoint should reject events when no valid verifier is configured, rather than silently accepting them. At minimum, a loud warning should be logged.

Suggested Fix

- default:
-     v = &verifier.NoopVerifier{}
+ default:
+     a.A.Logger.Error("No valid verifier configured for source",
+         "source_id", source.UID,
+         "verifier_type", verifierConfig.Type,
+         "mask_id", maskID)
+     _ = render.Render(w, r, util.NewErrorResponse(
+         "Source has no valid verifier configured. Events cannot be accepted.",
+         http.StatusForbidden))
+     return

If there is a legitimate use case for the NoopVerifier (e.g., development/testing), it should be explicitly opt-in with a NoopVerifier type, not a silent fallback.

Impact

• Severity: High — Any HTTP source without a properly configured verifier accepts unauthenticated events
• Who is affected: All self-hosted Convoy deployments that create HTTP sources without explicitly setting a verifier type

Positively — happy to submit a PR if this is welcome.

[linear]

PDE-765