Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Clear all filters


The ASM module first scans the request for violations. Without violations the request is then forwarded to the webserver. Next, the ASM module scans the response for violations. Currently, HTTP Response code 500 will raise a blocking page.

  • Allowed HTTP codes can only be added globally in the security policy (and automatically applies to all URIs and all source IP addresses).
  • Source IP addresses can be whitelisted, but will bypass the whole ASM module.
  • iRule: ASM:unblock is not supported in ASM_RESPONSE_VIOLATION event.

One solution would be to create these conditions in a HTTP policy and enable different ASM security policies. But then we have to maintain another security policy or setup a new parent policy and two children that inherit all parent policy attributes. One child is able to decline the generic policy settings and allow response code 500.

What's the best practice to allow HTTP response code 500 for just a few URIs and/or source IP addresses, preferable within one security policy.

Rate this Question

Answers to this Question


Allowing HTTP Response Code 500 to be returned to the client is a really bad design as it gives the potential attackers information on how to crash your application.

If you need to allow code 500 response for certain URLs then you can use ASM::disable in iRule

Comments on this Answer
Comment made 1 month ago by Jeroen Steenkamp 1

Thank you for your comments.

Our support department must be able to see the actual error message. We don't log responses on the F5, so we cannot see the error message based on blocking ID.

ASM:unblock only works on requests. Notice that the attack is a ASM_RESPONSE_VIOLATION.


The unblock command applies to requests only. It is not possible to unblock a response in which violations were found.

Comment made 1 month ago by samstep 1908

Hi Jeroen, I understand your requirements better now. So you need your Support team to see the error messages on 500 errors while you don't have response logging enabled on ASM. The solution here is to create a custom logging profile which will log responses on HTTP 500 responses ONLY and for specific URLs ONLY.

There is no point in whitelisting Support's IP addresses as surely the Support team will want to see the errors generated by all users and not just errors generated by the Support team (e.g. a 500 crash created by a user might not be replicable by the Support).

Alternatively you could capture any 500 response codes using an iRule and HTTP_RESPONSE event and log the error messages inside the iRule and then either rewrite the response as a redirect to a block page.