The security problem doesn't seem to have much to do with HTTP headers, really. If your back-end server is open to the network, the entire content of each request is suspect, right?
You need authentication; and you need to secure the channel from snooping and tampering. Each of these three facets of the problem has to be enforced in some protocol layer.
Take authentication. You need to: (a) stack HTTP on top of a network-level protocol that authenticates; OR (b) use some hypothetical flavor of HTTP authentication that's actually secure; OR (c) stack another authentication-capable protocol on top of HTTP--you know, SOAP with digital signatures or whatever they're doing these days.
Or take tampering. You need to: (a) stack HTTP on top of a protocol that provides a no-tampering guarantee; or (b) use some hypothetical HTTP feature that prevents tampering, like adding an HTTP header with a digitally signed hash of the message; or (c) stack another protocol on top of HTTP. Again with the SOAP.
Etc. The world of (a) contains multitudes, with no means of interoperability; the standards for (b) simply doesn't have the features you need; and the stuff at level (c) is despised by all right-thinking persons.