In order to secure its public HTTP API (so called REST), my client is asking me to implement a simple HTTP reverse proxy that will verify (OAuth 2.0) access tokens and forward HTTP requests to internal web services for processing.
The idea is that my client has "strong" network level security: the various web applications sitting behind the proxy would carry no security constraint as they cannot be accessed from the outside. They want to keep debugging easy when multiple internal services call each other. Plain http for internal calls, no TLS.
I'm thinking it's a terrible idea to leave internal applications "wide open" because any attacker that manages to get inside the network has basically free access to sensitive (cleartext) customer data... and history seems to prove that it happens a lot. From an operational standpoint, it will be a pain to enforce fine grain constraints like ACL from a proxy (OAuth scopes/URL matching), and maintain configuration up-to-date when new services are deployed.
Do you guys see anything I'm missing? Any additional argument for implementing application level security?
EDIT : Some important detail I did not clearly mention/explain :
- The web applications I'm talking about here (hiding behind only a security proxy) are all web services.
- Web applications with user interfaces (public/internal "sites") are in another network zone, and carry some decent application-level security compared to the web services in question.
The "strong" network security I mentioned is all about zones, end-users (and unauthorized insiders) theorically cannot access the web-services directly (only through the proxy). I guess ops could still offer some kind of route when they access the machines, as stated in the answers.