FastAPI, by default, implements strict Content-Type header checking for incoming JSON request bodies. This necessitates that clients submitting JSON payloads include a valid Content-Type header, such as application/json, for the body to be successfully parsed as JSON data.

This strict enforcement serves as a defense mechanism against a particular class of Cross-Site Request Forgery (CSRF) attacks. The specific vulnerability arises in scenarios where applications operate within a local network (e.g., localhost) or an internal network and forego explicit authentication, relying solely on network access for implied trust. In such environments, malicious websites can exploit browser behaviors where fetch() requests, when initiated with a Blob body and *without* an explicit Content-Type header or authentication credentials, bypass the standard CORS preflight check. Consequently, a cross-origin request from a malicious site could be made to a local application. If the local application were to indiscriminately parse any incoming body as JSON, irrespective of the Content-Type header, it could inadvertently process malicious commands from an un-preflighted, cross-origin request.

For instance, a local AI agent API at http://localhost:8000/v1/agents/multivac, lacking authentication and trusting the local network, could be targeted. A malicious external website (e.g., https://evilhackers.example.com) could use fetch() with a Blob body to send commands to this local API. Despite the different hosts, the browser would not trigger a CORS preflight because no credentials are sent and it interprets the request as not sending JSON due to the missing Content-Type header. FastAPI's default strict checking prevents such requests from being parsed as JSON, thereby thwarting this specific attack vector.

This CSRF risk is primarily pertinent to applications deployed on local or internal networks where network trust is the sole security perimeter. For applications exposed to the open internet, where authentication is a fundamental security layer, this specific attack vector is generally not applicable, as attackers would simply bypass browser-based restrictions by sending direct requests without browser interaction.

Should the need arise to support clients that do not transmit a Content-Type header for JSON payloads, FastAPI allows disabling this strict check. This is achieved by initializing the FastAPI application instance with the parameter $strict_content_type = False$. When this setting is applied, requests lacking a Content-Type header will still undergo JSON parsing of their body, mirroring the behavior of FastAPI versions prior to 0.132.0, when this feature was introduced.