ASM::violation full description of all keys

I believe the answer to your question can be found here:

https://support.f5.com/kb/en-us/solutions/public/11000/600/sol11680.html

The exact details vary by version, so your best option is to read the solution article.

I doubt you will be able to find the description of the all the violation detailed data keys/value pairs as it is undocumented by F5 on purpose. It also changes from version to version and can be modified by a HotFix.

The idea of what you (or your customer) are trying to do does not make any sense to me from the web application security best practices standpoint. ASM is a Web Application Firewall(WAF) and it is there to BLOCK the attack BEFORE it reaches the application. If they want ASM to only DETECT the attacks and then convert all the attack details to HTTP headers and have the application developers to code some sort of a decision engine whether the application itself should disallow the request then:

a) it is too late as the attack has already happened and any vulnerability possibly present in the application is already exploited. It is a bit like asking your security guard to allow a gang of robbers and other criminals into your house, but asking the security guard to give you a printed report of why the criminals should have been stopped by the security guard in the first place.

b) if your customer can code a decision engine inside the application they might as well code the application in a secure way in the first place so it is not vulnerable to OWASP Top 10 attacks. A WAF is most useful for applications which cannot be changed easily (e.g. legacy, 3rd-party, developers not available, application change might take many months, etc).

c) conversion of violation_details into HTTP Headers using an iRule will take a huge amount of ASM's CPU power and will not scale. An attacker can simply flood your system with an attack which matches thousands of signatures 10,000 times per second. Both your ASM and your application will be dead trying to convert all the details into HTTP headers.

Having said that I do see some value in having [ASM::violation_data] (not detailed data) being sent as headers for non-blocking violations, e.g. attack_type and viol_name - these will be constant and predictable across all violations.

You might (key word here is might) be able to get your sales team to get you such a list, but be aware that you will need to update that list each and every time you apply a new signature set. Maintaining what you are proposing will be non trivial.