Serverless event input validation: queues, blobs and webhooks

Treat the payload of every trigger as untrusted input, including queue messages, storage events and messages from other internal services. Microsoft's Azure Functions guidance states that triggers and bindings provide no extra data validation, and that your code must validate what it receives, because an upstream service may be compromised.

The false comfort of internal triggers

Teams often put authentication and validation on the HTTP endpoint and skip it for functions triggered by a queue, a storage upload or a timer. The reasoning: only our own systems can write there.

That holds until it doesn't. A queue may be written by a service that itself accepts user input. A storage container receives files uploaded by customers. A message topic may be shared with a partner. A compromised upstream system sends whatever it wants. The Azure documentation says exactly this: if an upstream service is compromised, you do not want unvalidated inputs flowing through your functions.

What to validate

1. Shape. Required fields present, types correct, sizes bounded. Reject unknown fields if the schema is closed.
2. Value ranges. Lengths, numeric limits, allowed enumerations.
3. Identity. Never trust a user identifier inside a message just because it sits there. Confirm the sender is authorized to act for that user.
4. Names and paths. A storage event carries an object name. A name can contain path characters or unexpected encoding. Do not feed it to a file path or shell without checks.
5. Content. An uploaded file is not the type its name claims. Check before parsing, and parse in a way that limits resources.

Injection still applies

Microsoft's own example: a function that stores data from a storage queue into a relational database must validate the data and parameterize its commands to avoid SQL injection. The same logic covers shell commands, template engines, outbound HTTP requests built from message fields and log messages that include raw input.

Output validation too

The guidance also suggests verifying data written to output bindings. A function sits between systems. If it forwards malformed data downstream, it spreads the problem.

Error handling is part of the design

Unhandled errors bubble up to the host and the runtime handles them in binding specific ways. For a queue trigger this may mean retries of a bad message. Decide in advance: reject, send to a dead letter location, alert. A poison message that retries forever costs money and hides real work.

A template for each trigger

1. Write down who can produce events for this trigger.
2. Write the schema, with bounds.
3. Validate at the top of the handler and fail fast.
4. Use parameterized calls for every data store and command.
5. Log a safe summary of rejected inputs, not the full payload.
6. Test with malformed, oversized and hostile samples.

Click through it at your own pace, or open it full screen.

Quick check

Safeguard's code and dependency scanning, plus the free scan, help find missing validation and vulnerable parsers.

Sources

• Securing Azure Functions, Microsoft Learn

Last reviewed: 19 October 2026.