As I learn about web app security, the focus seems to be on the going-ons between the client and the app server. To illustrate, SQL injection and SSL certificates both seem to me to be mainly concerned with the connection between the app server and clients - or the logic and the presentation tiers.

My web application uses a connection string to access a database. The connection string is secured and encrypted... but when the connection is active, couldn't someone intercept that connection and effectively "sniff" what is being stored and read?

4 Answers 4


If you configure the app to use TLS to connect to the db then it cant be sniffed. If that is being done along with everything else you are fine. The connection string is decrypted in memory so somebody will have had to compromise one of the machines in order to get anything of use. Of course precautions need to be taken there as well, but as far as sniffing, it cant be done if TLS is used.


My web application uses a connection string to access a database. The connection string is secured and encrypted... but when the connection is active, couldn't someone intercept that connection and effectively "sniff" what is being stored and read?


In a typical small web applications configuration, you'd be running your database on the same machine as your web server and application. In this case, the connection between your application and the database would be protected by operating system, which enforces that loopback address or domain socket can only be accessed from local processes. There's little to gain here from encrypting the connection.

In another setup, you might have a physical wire connecting two machines on the same rack. The rack might be placed in a secured data center in a caged rack, where you're happy with the data center's security parameter, or it might be in a locked closet in the office, and you're happy with trusting the employees not trying to deliberately break into the closet. In this case, adding encryption might be overkill.

In a similar situation as previous paragraph, but now you have an outdated router between your machines. Problem is that this router runs outdated software with known vulnerabilities, or you don't trust its Virtual Networking configuration, or it doesn't support such features, or you're worried about remote take over of the router's web administration. Then you might want to add TLS encryption and mutual authentication to cover up deficiencies in the outdated router.

In another typical case, you might run your database and web server in multiple VMs in a public cloud provider, you might want to add inter machine encryption, or you might decide that the cloud provider's network access control is not trustworthy enough for the kind of data you're dealing with. You might run a VPN between the machines or an encrypted overlay network on top of the existing network infrastructure.


Traditionally, network encryption ends at the edge: a load balancer or one of the first machines after it handles TLS decryption, and all internal traffic is unencrypted. This comes from a trust of the internal network and the difficulty of setting up encryption between every machine.

You are correct that an attacker who can sniff internal traffic can exploit this to observe all database traffic in this sort of setup. This idea (although on a broader scale, between datacenters) is at the core of the NSA and GCHQ program MUSCULAR, and after it was revealed, several large tech companies publicly announced they were now encrypting internal traffic.

As to specifics, yes, most databases support TLS connections.

The question as always is whether this is something that fits into your threat model. What sort of attackers do you need to protect against? What sort of data are you holding? If you're running, say, a WordPress install for your kid's soccer team, setting up encryption to the database is probably overkill. If you're a credit card processor, then it's probably not. You have to decide for yourself what makes sense in your situation.


There is nothing about TLS that limits you from using it to secure the connection between the application server and the database. You can go ahead and have the communication TLS-protected. Some organisations that are dealing with highly confidential information, will usually take an extra step. IF for example they require extra security for certain elements of their traffic (credit card information, etc.), it's usually necessary to deploy a solution that can implement a column specific encryption and access control.

In such a situation the solution would need to put an encryption module on both the database and the application server to ensure the granular encryption approach.

Disclosure: I worked as a consultant on one of such solutions

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .