Update an ASM Policy Template via REST-API - the reverse engineering way

I always want to automate as many tasks as possible. I have already a pipeline to import ASM policy templates. Today I had the demand to update this base policies. Simply overwriting the template with the import tasks does not work. I got the error message "The policy template ax-f5-waf-jump-start-template already exists.".

Ok, I need an overwrite tasks. Searching around does not provide me a solution, not even a solution that does not work. Simply nothing, my google-foo have deserted me. Quick chat with an AI, gives me a solution that was hallucinated. The AI answer would be funny if it weren't so sad. I had no hope that AI could solve this problem for me and it was confirmed, again.

I was configuring Linux systems before the internet was widely available. Let's dig us in the internals of the F5 REST API implementation and solve the problem on my own.

  1. I took a valid payload and removed a required parameter, "name" in this case. The error response changes, this is always a good signal in this stage of experimenting. The error response was "Failed Required Fields: Must have at least 1 of (title, name, policyTemplate)".
  1. There is also a valid field named "policyTemplate". My first thought: This could be a reference for an existing template to update.
  1. I added the "policyTemplate" parameter and assigned it an existing template id. The error message has changed again. It now throws "Can't use string (\"ox91NUGR6mFXBDG4FnQSpQ\") as a HASH ref while \"strict refs\" in use at /usr/local/share/perl5/F5/ASMConfig/Entity/Base.pm line 888.". An perl error that is readable and the perl file is in plain text available.
  1. Looking at the file at line 888: The Perl code looks for an "id" field as property of the "policyTemplate" parameter. Changing the payload again and added the id property. And wow that was easy, it works and the template was updated.

Final the payload for people who do not want to do reverse engineering.

Update

POST following payload to /mgmt/tm/asm/tasks/import-policy-template to update an ASM policy template:

{
    "filename": "<username>~<filename>",
    "policyTemplate": {
        "id": "ox91NUGR6mFXBDG4FnQSpQ"
    }
}

Create

POST following payload /mgmt/tm/asm/tasks/import-policy-template to create an ASM policy template:

{
    "name": "<name>",
    "filename": "<username>~<filename>"
}

Hint: You must upload the template before to /var/config/rest/downloads/<username>~<filename>".

Conclusion

Documentation is sometimes overrated if you can read Perl. Missed I the API documentation for this endpoint and it was just a exercise for me?

Published Feb 17, 2026
Version 1.0
APM
devops
Distributed Cloud
security

6 Comments

  • Juergen_Mang's avatar
    Juergen_Mang
    Icon for MVP rankMVP
    Feb 25, 2026

    If you have 100 policies deployed from a template updating the template will only update new policies that are made from this template right?

    I think so. I rarely configure policies manually. If you use the declarative way, the updated template is used as soon you freshly deploy your declaration.

    I use the ASM policy templates only as a blank template, even more disabled and configured as the Blank template from F5. It is the best way for a declaration to start from scratch and not with some defaults from a template.

    I never user Parent policies, they are crap in my opinion.

    They are two solutions:

    1. Use a declaration
    2. Use a script to update your 100 policies

    Both is easily possibly with my Axians Automation Framework ;)

    A Restsh script could look like:

    while read -r POLICY
do
    f5.asm.entity.add -t entity.urls-allowed.json -sVAR_ALLOWED_URL=/new-uri "$POLICY" urls
done < <(f5.asm.policy.list -rf ".items[].fullPath")

     

    • Nikoolayy1's avatar
      Nikoolayy1
      Icon for MVP rankMVP
      Feb 26, 2026

      Starting to become more and more interested in your  Axians Automation Framework :)

      Yes parent policy is not good as it seems to only be able to push global signature or violation changes to the children but an iRule can do this as well đź™…

  • Nikoolayy1's avatar
    Nikoolayy1
    Icon for MVP rankMVP
    Feb 25, 2026

    Juergen_Mang​  nice article ! If you have 100 policies deployed from a template updating the template will only update new policies that are made from this template right?

    I thought I can add an explicit url under the Parent policy and this to be pushed to all child ones but Parent policies do not allow this for some reason.

    iRules seem the only way but F5 doesn't seem to have an irule event triggered before the WAF/ASM as for example to stop the body checks based on URL and content-type match that can be attached under all VS for example.