Remaining reqs in section 5.1 seem like they don't belong.

[tghosth]

These requirements are not really input validation but it is not clear where they should go.

#	Description	Level	Suggested action
5.1.5	[MODIFIED, SPLIT TO 50.8.1] Verify that the application will only automatically redirect the user to a different URL directly from an application URL where the destination appears on an allowlist.	L1 or L1>L2	Leave here but open a separate issue to discuss location
5.1.6	[ADDED] Verify that the application validates that user-controlled input in HTTP request header fields does not exceed the server's maximum header field size limit (usually 4kB or 8kB) to prevent client-based denial of service attacks.	L2	Leave here but open a separate issue to discuss location

Previous thoughts:

@elarlang:

V5.1.5 is not just a technical input validation - it relies on logic and a defined list to define, what is a trusted and allowed destination.

V5.1.6 it is a technical check, but during a building the header. It may involve more than one input or other logic - just that the combined length that is used in one header field value can not exceed defined limit. It is a question of program code logic and fits to defensive coding.

(apologies in advance if I missed anything)

@tghosth:

5.1.5 sounds like classic "accept or reject it" validation so I think this should stay put.

5.1.6 is not language specific but rather a conceptual question of how you incorporate untrusted content into a header. I still think it is more about input than logic but I am not strongly opinionated.

[jmanico]

5.1.5 looks like validation to me. It's typically called "allow list validation" and this kind of validation does in fact almost always provide a needed security benefit when protecting redirects.

5.1.6 is just doing a size limit check, a form of validation. Depending on the underlying framework, a programmer doing this manually may or may not provide a major security benefit.

But these both seem like security validation to me.

[elarlang]

5.1.6 can be also widened to building a request URL (to an API) - it may happen in the background without processing directly the request initiated by the user - so it is not direct user input validation. Probably we need to change the 5.1.6.

[jmanico]

Especially since 5.1.6 is something a developer rarely needs to deal with, I agree on moving it out of validation, Elar.

[tghosth]

For 5.1.5, I think the closest sections are either "V5.2 Sanitization and Sandboxing" because it fits into the theme of only using untrusted content after we are sure that it is safe.

For 5.1.6, I would welcome a suggestion from @elarlang on how to alter the requirement and where it should go.