Re: HTTP request validation guidelines for implementers

Am 08.07.2021 um 20:18 schrieb João Penteado:
> Greetings everyone,
>
> This is my first time posting on a IETF mailing list, so I apologize in advance
> if this isn't the proper channel for this discussion.
>
> Input validation is a critical security component of most information systems,
> and this is especially true for public services available over a untrusted
> network such as the Internet.
>
> In the context of HTTP requests, there're several opportunities for early
> request validation and many systems employ an dedicated initial validation layer
> either internally, as "request middleware", or externally in the form of layer 7
> firewalls, AKA Web Application Firewalls (WAFs), or reverse proxies.
>
> It is usually in both the server's and the client's best interest that an
> invalid request be rejected as soon as possible and that meaningful error
> information be sent back to the client. For this very purpose, RFC7231 defines a
> whole class of HTTP error status code (4XX).
>
> However, when implementing an HTTP server, there is no standardization or
> consolidated guideline that I could find that address these two points:
>
> 1. Which components of the request MUST and SHOULD be validated.
> 2. In which order SHOULD these components be validated.
> ...

I agree that (1) is an interesting question, and in a perfect world the
spec will state that. If it does not, we may want to improve it.

With respect to (2) I'm very sceptical: ordering of validation steps
often depends on implementation details. Why does it matter in practice?
(I understand that it would help in comparing validators, but besides
that???)

Best regards, Julian

Received on Friday, 9 July 2021 10:43:12 UTC