The weakest link is always the application at the end of the chain. Reverse proxying is basically handing down the request to another server, so what really matters IMHO is what you expose of the application to the upper layers and what those who access it can do with it. Considering the application will also be on an internal network and interprets what the client is sending, that's where you should worry most.
So, dealing with reverse proxies as long as you don't "proxy everything" ( as in all paths ) and you just let through the absolute minimum in data and methods for the application to work I don't think the reverse proxy is of much concern. El sáb., 15 may. 2021 17:48, Jim Albert <j...@netrition.com> escribió: > On 5/15/2021 10:21 AM, Jason Long wrote: > > Hello, > > Is proxy to proxy improving the security? For example: > > > > The Internet --> Reverse Proxy Server --> Reverse Proxy Server --> Web > Site > > > > It really depends on what functions your proxies are performing. For > example, are the reverse proxies simply load balancers or do they also > serve as a WAF (Web Application Firewall)? A combination of both > services on the same reverse proxy is a common implementation often > offered commercially. Weeding out malicious requests falls on on the > reverse proxy WAF while the backend web servers are free to spend their > resources on legitimate requests. > > I think part of the answer is for security don't completely rely on your > reverse proxy to keep out all malicious activity. It should do a good > job. None the less you still want your backend free of vulnerabilities > like XSS and SQLi. > > I think you'd have to define more of the purpose of multiple reverse > proxies. > > Jim > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
