I want to throw in some alternative view points here.
I do not necessarily support the given requirement , I am only giving a Possible Justification for why it is the way it is.
(1) When the scan is reporting a "Security Vulnerability" , we have to consider for whom it is a vulnerability.
It is not that this missing header will somehow allow hacking into the web server or even hacking into the web client or will somehow reveal Confidential Data.
It is actually the whole "Payment Network" here , and the vulnerability is the Possibility of unintentional false tampering.
(2) Thanks to user "josh3736" for sharing https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf , where I got some idea about what the Issue is supposed to be.
It is requirement "11.6 Unauthorized changes on payment pages are detected and responded to"
When the web browser ( user wants to make a Payment ) is accessing the web server ( Payment Network wants to authenticate that Payment ) , things will go smooth even when that header for HTTP 204 is rightly missing.
In case there are Server Proxies , Client Web Access Proxies , Payment gateways , ISP filters , or Cloud Servers involved in the network transaction , there are chances that some overly-enthusiastic Proxy ( or Intermediate Element ) will set Default Content-type ( or will insert Content-type when that is missing ) & that might get Detected.
That Detection might ( will ) make the transaction fail even though there is no real Issue here. That false Positive resulting in transaction failure might then result in unnecessary losses to Customer or to Business.
To avoid that , there should be no unknowns & no Defaults : all things should be Explicitly known in the Security Environment.
Thus the requirement that the Content-type Header ( & all other things ) be set makes sense.
The requirement could be modified to state that there should be no such header when it is not necessary , though there is no guarantee that Intermediate Elements will not insert it , to make false Positives.
Better use a header Explicitly & Ensure that it is not getting tampered.
END Of Answer
Interested folks may be curious to check Page 261 & Page 262 of the PCI DSS Document.
It is listed like this :
11.6 Unauthorized changes on payment pages are detected and responded to.
11.6.1 A change- and tamper-detection mechanism
is deployed as follows:
• To alert personnel to unauthorized modification
(including indicators of compromise, changes,
additions, and deletions) to the HTTP headers
and the contents of payment pages as received
by the consumer browser.
• The mechanism is configured to evaluate the
received HTTP header and payment page.
...
By comparing the current version of the HTTP
header and the active content of payment pages
as received by the consumer browser with prior or
known versions, it is possible to detect
unauthorized changes that may indicate a
skimming attack.
...
The intention of this requirement is not that an entity
installs software in the systems or browsers of its
consumers, but rather that the entity uses
techniques such as those described under
Examples in the Guidance column to prevent and
detect unexpected script activities.
...
Examples
Mechanisms that detect and report on changes to
the headers and content of the payment page
include but are not limited to:
...
Reverse proxies and Content Delivery
Networks can detect changes in scripts and
alert personnel.
Often, these mechanisms are subscription or
cloud-based, but can also be based on custom
and bespoke solutions.
