Lesson 11: Protect JSON, XML and APIs with the Right Content Handling

F5 ASM CLASSROOM • LESSON 11

Level: Intermediate to advanced  |  Suggested study and lab time: 75 minutes
Instructor: Harpreet Singh Virdi, CISSP, CCSP

Start Here / Course Guide · All lessons

---

APIs still speak HTTP

A browser page and an API can use the same network path while carrying very different bodies. An API might send JSON to /api/orders; an older integration might send XML. A WAF needs to interpret that content correctly before meaningful validation can occur.

Our example API

POST /api/orders
Content-Type: application/json

{"bookId":42,"quantity":1}

The application contract says bookId and quantity are integers, quantity is required, and unknown fields have a defined treatment. Those are requirements to implement and test, not guarantees supplied by the Content-Type header. Clients can send incorrect or misleading headers.

Profiles and contracts

A content profile supplies parsing and validation settings for a body format. Check how the URL and content-type handling select the JSON or XML profile. Where supported, a schema or OpenAPI specification can help describe expected operations and input. Supported schema versions, import behavior, and enforceable constraints vary by release.

Do not assume that importing an OpenAPI file enforces every security requirement in it. Review import messages, generated entities, and unsupported features. Authentication and object-level authorization still require application enforcement.

Guided JSON lab

1. Document the method, path, content type, and expected fields for one synthetic endpoint.
2. Inspect which content profile actually handles requests to that URL.
3. Configure supported parsing and validation according to your installed release.
4. Send a valid JSON body and confirm normal application behavior.
5. In your lab, test malformed JSON, the wrong value type, an omitted required field, an unexpected field, and a boundary-length value.
6. For each case, record whether ASM or the application rejected it and which rule explains the result.
7. Test the same body with an unexpected content type to understand the configured fallback handling.

Expected result: the valid body succeeds, malformed input is handled as configured, and you can distinguish syntax validation from contract validation. A JSON parser can recognize valid JSON while still accepting a semantically invalid order.

XML differences

XML introduces elements, attributes, namespaces, and potentially schema validation. Start with the application's actual message format. Coordinate parser security with developers, including external-entity behavior and resource limits. Do not reuse JSON assumptions for XML simply because both carry structured data.

OpenAPI exercise

If your release supports the required specification, import a minimal approved lab definition. Review the resulting methods, paths, parameters, and content rules. Then change the specification to add one new operation and inspect the policy difference before applying it. The policy and API release should evolve together.

Knowledge check

Does a successful schema check prove the caller may access order 42?

Instructor answer

No. Structure and authorization answer different questions. The application must verify that the authenticated caller is permitted to act on that specific order.

---

Further reading

• F5 documentation: working with openapi
• F5 documentation: adding entities to a security policy

Independent educational material. Menus, defaults, and feature availability vary by BIG-IP release and license. Use the documentation for your installed version. Perform exercises only in your authorized lab. Examples and expected results are instructional; these labs have not been executed on a BIG-IP device for this blog.

← Previous lesson · Course guide · Next lesson →