@fidoboy in my experience, when this “lack of confirmation header” comes up, it’s sometimes because a plugin or theme other than the Font Awesome plugin is acting in an expected way during these requests and is emitting some output to the request that is unexpected. Another plugin might assume that it’s operating in the context of a request that has an HTML response, instead of a REST API context where a JSON formatted response body is expected, so that plugin might emit HTML content, resulting in a malformed response. This confirmation header mechanism was added as a way to help point out when that is happening.
So, especially if it seems to have suddenly happened, I would ask: what recent changes have you made related to other plugins, or possibly your theme? Especially anything to do with caching, proxying, or security?
Another way to get a clue as to what other code might be responsible for this is to look at the body of the HTTP response that has the 403 status, in the network tab of the browser console. Can you inspect that? Sometimes it will be obvious, because it will include something self-referential in an HTML error message from the responsible code that identifies itself as the source of the message.
A different kind of cause might be: something like a proxy that has recently been placed in front of your WordPress server, like Varnish, and that proxy has a too-strict policy for what routes it allows, so it returns a 403 HTML response, despite the expectation for a JSON response, before even allowing the request to reach the origin WordPress server.
