In one of the existing batch process codebase, I can see a practice of JDBC Connection String is getting logged and also persisted. Logging or Persisting a JDBC Connection String alone may not be a security issue. Though, it's a little discomforting to make this information available to naked eyes. But is it a best practice to do so? If not, is there any other reason? OR Is there any usefulness to this practice?

  • By connection string I guess you mean the jdbc:vendor://host:port/database right? Just to make clear we are not speaking about prepared statements. – Laiv Apr 4 at 13:22
  • You are correct, it's the Connection String not the Statement... – Divs Apr 4 at 13:24
  • What kind of details are logs providing you with? It would not surprise me if these logs were keeping traceability between applications - sessions - databases. – Laiv Apr 4 at 13:28
  • The entity ids of Source and Sink are logged, which is typically same, along with Job Id. The job is responsible to migrate data from One System to Another.. – Divs Apr 4 at 13:33
  • 1
    Looks like monitoring and traceability. – Laiv Apr 4 at 13:49

Knowing which database an application is connecting to can be very useful when there are multiple possibilities. But you don't need the entire connection string for that.

I agree with you that doing this is in general a bad practice. An application should know what it's logging and the connection string is generally just that. A string passed in from configuration that could contain anything.


As long as the credentials are not being passed in the connection string (I think you can do this at least with some drivers) I don't think this is a significant security concern. Aside from those details, what would be considered secret about this information? Typically the port is standard and well-known.

At best, trying to hide this information would be considered security by obscurity. With security considerations, it's helpful to consider who you are defending against. For most organizations, insiders are the most likely attackers. Would removing this information significantly impede someone within the organization? I kind of doubt that. For an external attacker, if they have the chops to get into your database, they can surely find it.

Alternately, not logging this potentially creates risks. What if an attacker is able to modify the configuration to point to something they control? If you don't log this information, it could make it a lot easier for them to cover their tracks.

If you are concerned about the information in logs (which is perfectly reasonable) you should probably focus on securing the logs. Trying to prevent any sensitive information from being logged is a endless game of whack-a-mole and success is unlikely over the long-run.

  • 1
    Would downvoter care to say why? Security is measured and implemented upon feasible attack vectors and feasible treats. You might or might not agree with At best, trying to hide this information would be considered security by obscurity. but it doesn't invalidate the rest. – Laiv Apr 4 at 13:54
  • @Laiv If there's disagreement about whether this is more than security through obscurity, then I think discussion about how that is would be great. – JimmyJames Apr 4 at 14:27
  • DB Queries are handled to prevent injection attacks in the app; So, I'd think, changing the source alone can't make a big difference? Also, to reflect a new source we would require a restart of the apps and hence can't affect the app dynamically through in-memory changes. Logs and DB has both source and sink ids for traceability, On the other hand, persisting the info in sink DB, also reveals information about the source, which is not-a-best-practice to my understanding? And for Suppt activities, we don't need to persist this info, they have access to SCM anyway. What am I missing, please? – Divs Apr 5 at 3:27
  • @Divs "So, I'd think, changing the source alone can't make a big difference?" You are saying that someone pointing your app to a fake database that steals data or worse is no big deal? I'm not sure I follow that. – JimmyJames Apr 5 at 13:29
  • @JimmyJames The source info configured and is injected during initialization Only. To change the source the has to be restarted, which will re-read from the config again, hence I believe it is not possible to do so in our arch/design. – Divs Apr 5 at 13:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.