Add system tests for WAF Blocking Response Unique Identifier (RFC-1070)

[jandro996]

Motivation

• Add RFC-1070 system tests for blocking response unique identifiers
• Verify that blocking responses include a unique security_response_id (UUIDv4) in all response formats
• Test coverage includes:
  • JSON blocking responses with security_response_id
  • HTML blocking responses with security_response_id element
  • Custom redirect URLs with security_response_id query parameter
  • Traces with blocking events contains security_response_id
  • Uniqueness validation across multiple blocking requests

Changes

• New test file: tests/appsec/waf/test_blocking_block_id.py
• Enhanced tests/appsec/waf/test_blocking.py works with new and old template versions
  -Added blocking_response_id feature flag (feature_id=493) in utils/_features.py

Workflow

1. ⚠️ Create your PR as draft ⚠️
2. Work on you PR until the CI passes
3. Mark it as ready for review
   • Test logic is modified? -> Get a review from RFC owner.
   • Framework is modified, or non obvious usage of it -> get a review from R&P team

🚀 Once your PR is reviewed and the CI green, you can merge it!

🛟 #apm-shared-testing 🛟

Reviewer checklist

• If PR title starts with [<language>], double-check that only <language> is impacted by the change
• No system-tests internal is modified. Otherwise, I have the approval from R&P team
• A docker base image is modified?
  • the relevant build-XXX-image label is present
• A scenario is added (or removed)?
  • Get a review from R&P team

[github-actions]

CODEOWNERS have been resolved as:

tests/appsec/waf/blocked.v3.min.html                                    @DataDog/asm-libraries @DataDog/system-tests-core
tests/appsec/waf/blocked.v3.min.json                                    @DataDog/asm-libraries @DataDog/system-tests-core
tests/appsec/waf/test_blocking_security_response_id.py                  @DataDog/asm-libraries @DataDog/system-tests-core
manifests/cpp_nginx.yml                                                 @DataDog/system-tests-core
manifests/dotnet.yml                                                    @DataDog/apm-dotnet @DataDog/asm-dotnet
manifests/golang.yml                                                    @DataDog/dd-trace-go-guild
manifests/java.yml                                                      @DataDog/asm-java @DataDog/apm-java
manifests/nodejs.yml                                                    @DataDog/dd-trace-js
manifests/php.yml                                                       @DataDog/apm-php @DataDog/asm-php
manifests/python.yml                                                    @DataDog/apm-python @DataDog/asm-python
manifests/ruby.yml                                                      @DataDog/ruby-guild @DataDog/asm-ruby
tests/appsec/blocking_rule.json                                         @DataDog/asm-libraries @DataDog/system-tests-core
tests/appsec/waf/test_blocking.py                                       @DataDog/asm-libraries @DataDog/system-tests-core
utils/_features.py                                                      @DataDog/system-tests-core

[Anilm3]

The Block ID is provided as part of the event / trigger, would it not be better to assert its presence use that to validate the response rather than setting the ID to a known value?

[jandro996]

The Block ID is provided as part of the event / trigger, would it not be better to assert its presence use that to validate the response rather than setting the ID to a known value?

You are right! Refactored to use the actual block_id from the response for validation instead of normalizing to a placeholder.