Does This Web Application Really Need to Be Behind the VPN?

For a long time, putting a web application inside the corporate network was considered an obvious security decision. If an application was intended only for employees, the reasoning was straightforward. Do not expose it to the Internet. Put it on the internal network and require employees to connect through the corporate VPN.

There are certainly applications and environments where that still makes sense; for example, applications that are not web- or mobile-based. But I am increasingly unconvinced that it should be the default answer. Consider a relatively ordinary web application used by employees. We decide that the application is sensitive enough that it should not be accessible from the Internet. We place it inside the corporate network and require employees to establish a VPN connection before they can use it.

The employee is now connected to the same corporate environment containing substantially more important things than the web application we were trying to protect. That network may contain databases, administrative interfaces, file servers, legacy systems, development environments, management infrastructure, and perhaps even a mainframe. It also contains laptops belonging to executives, administrators, developers, and other employees.

We protected the web application by giving the person who needs it a pathway into an environment containing things that are considerably more sensitive than the application itself. That seems worth examining.

The problem becomes more obvious with third parties

Now suppose the web application is also used by a vendor. The vendor does not work for us, their laptop is not ours, and their security program is not ours. But they need access to the application.

Because we decided that the web application is safer inside the corporate network, we now have to construct a mechanism that allows someone outside the organization to connect to the corporate network. We may create a special VPN profile, add network segmentation, build firewall rules restricting where the vendor can go, or implement additional monitoring and authentication.

Those are reasonable controls, but there is an architectural question underneath all of them. Why did this person need a connection to our corporate network in the first place? The answer may simply be that the application they need happens to live there. That is a very different justification from actually needing access to the corporate network.

Network location is not application security

There is another assumption hiding inside this architecture. We tend to think an internal application is safer because an attacker cannot reach it directly from the Internet. That is true in one specific sense. The application has less external exposure. However, reduced exposure should not be confused with a secure application.

An web application does not stop needing strong authentication because it is internal. It does not stop needing authorization controls, vulnerability management, secure configuration, logging, monitoring, patching, secrets management, and a secure development lifecycle. An internal application can still contain SQL injection, have broken access controls, and use vulnerable libraries.

If we are serious about zero trust and assume-breach principles, we should not design the application around the assumption that everyone who can reach it is trustworthy. Besides malicious insiders, the more common scenario is the sincere employee whose laptop is infected or who has unfortunately clicked a phishing link.

Once we accept that, something interesting happens. Many of the security controls we would need before exposing the application externally are controls we should have implemented regardless.

The VPN solves a different problem

A VPN can provide an encrypted connection into a trusted network and can be entirely appropriate when someone actually needs access to resources within that network, but that does not mean every workforce application belongs behind one. The distinction matters.

There is a difference between saying:

"This person needs access to our corporate network."

and:

"This person needs access to an web application."

Those are not necessarily the same requirement. If someone needs to administer servers, access management interfaces, reach legacy systems, or perform work that genuinely requires network-level connectivity, a VPN may be exactly the right tool. If someone needs to submit an expense report from a browser, the architectural justification is less obvious, yet we frequently solve both problems with the same mechanism.

A VPN connection is also a trust decision

There is another side of the VPN connection that is easy to overlook. When we require someone to connect to the corporate VPN to reach an web application, we are not merely providing the user with access. We are allowing their device to establish connectivity into our environment. Those are two sides of the same decision.

The VPN can authenticate the user and encrypt traffic between the endpoint and the organization. Neither of those things necessarily tells us that the endpoint itself is trustworthy.

The laptop could be infected with malware, missing security updates, or have its endpoint protection disabled. It may be a personally owned device over which the organization has very little control. In the case of a contractor or vendor, it could be a device managed according to an entirely different organization's security standards.

Modern device-trust controls can substantially reduce this risk. Conditional access policies, endpoint posture assessment, managed-device requirements, certificates, EDR integration, and similar controls can help determine whether a device should be permitted to connect. But those controls are not universally deployed, and even a well-managed endpoint is not guaranteed to be uncompromised.

This creates a strange situation. We may have an employee who needs access to a single web application, something a browser is specifically designed to do across the Internet. Because we consider the application safer on the internal network, we require the employee's entire device to establish a connection to that network instead.

If that endpoint is compromised, we have potentially given the attacker something they did not previously have: network reachability. Segmentation and restrictive VPN access policies can limit that exposure, and they absolutely should. But once again, we are adding controls to mitigate a risk created partly by the architectural decision to require network access in order to provide application access.

That does not make VPN access inherently unsafe. It means the security analysis needs to account for both directions of the trust relationship. We should ask not only whether we trust the user to access the corporate network. We should also ask why the corporate network needs to trust the user's device at all. If the person only needs access to one web application, that is not a trivial distinction. Just because someone provides a service to the company does not necessarily mean they need to access the network.

There is also a workforce cost

This architecture has consequences beyond security. A web application is naturally well suited to a distributed workforce. A browser, an Internet connection, strong authentication, and an appropriately secured application can provide access from almost anywhere.

Put that same application behind the corporate VPN and we have created another dependency. The employee must establish connectivity to our network before they can establish connectivity to the application. That affects remote employees, contractors, and those traveling. It affects anyone trying to work when the VPN infrastructure is unavailable.

We took something built around distributed access and tethered it back to the corporate network. There may be good reasons to make that tradeoff. But it should be a tradeoff we consciously make, not one inherited from an architectural assumption made twenty years ago when we lacked zero-trust architectures, phishing-resistant MFA, device trust, and conditional access policies.

The question should change

I am not suggesting that organizations start moving internal web applications onto the public Internet without appropriate controls. Quite the opposite.

An Internet-accessible workforce application should have strong authentication, including phishing-resistant MFA where appropriate, along with device trust and conditional access policies appropriate to the application's risk. Authorization should be carefully designed. The application should undergo vulnerability management and security testing. Administrative functionality may warrant additional restrictions. Sensitive applications may require stronger controls still.

But those are application security and identity controls. They are also controls that a mature organization should want on the application even when it is internal. The better architectural question may therefore not be:

"Why would we put this application on the Internet?"

It may be:

"Why does using this application require access to our corporate network?"

Sometimes there will be an excellent answer. Sometimes there will not. And when there is not, putting the application behind the VPN may not have eliminated trust. It may simply have moved that trust somewhere else.