When building an n-tier/layered web application where each tier is physically separated from the others, is it important for a different communication stack to be used by the backend tier(s)—which are not exposed to the Internet—than the web tier that is?
Being security conscious in building a web application, I am building a middle-tier (backend-tier, application server) that handles all data access for the web application so that the web server never has direct access to the database.
I have been thinking I need to make the application server use a different communication protocol than that exposed on the web server. If my middle-tier exposes HTTP/REST web services using the same technology stack as the web server, would not the middle-tier be just as easily compromised?
As such, I have been making the middle-tier communicate by a binary TCP protocol while the web server exposes HTTP/REST webservices. The down side to this is all the additional overhead. I need to both define interfaces twice (once for the application server and once for the web server) and need to deal with two libraries/communication protocols and their quirks.
Is this the complexity that secure web application development demands? Am I right in needing to use different protocols/libraries the Application Server and the Web Server?
Edited to add: This concerns mitigation in the event the web server is compromised. The web server can do far less than the middle-tier (most notably, not access the database). An attacker compromising the of the web server would be bad; but, achieving unfettered access to the database would be far worse.