6

I have a REST API running in a Tomcat container that has an endpoint that takes a customer email address as a query parameter. It's something like this:

/customers?email=foo@bar.com

Customer email addresses are an asset we want to protect, so we need to ensure they aren't logged any where, and cannot be intercepted. The API only works over HTTPS and requires strong authentication.

When it comes to logging, in the application code, email addresses are not logged. However, all URLs the service get logged out in the Tomcat localhost_access_log, which include the query parameters. A plan is to use a different Tomcat access log valve that didn't log out query parameters in URLs. Would that be sufficient to ensure the email addresses don't get logged out. Is there anywhere else that typically logs out URLs that needs to be taken care of?

  • 3
    I have no experience with Tomcat APIs, but the problem you already noticed is that the email is submitted as a GET parameter, and GET parameters are always submitted as part of the URL. As you said, those parameters can be then found in Log files, but also in the History of a browser, a user could also bookmark the url, or send the link to someone else. Never send private data using GET parameters. Use POST for that. – stanko Jul 15 '15 at 8:51
  • I should have specified, this API is only accessed by other services. The only requests made from a browser will be in testing (with fake email addresses) from developers machines. No human user will have access to the API in production. I just wanted to know all of the possible places I should be looking to see where the URLs may get logged out – oggmonster Jul 15 '15 at 9:29
  • According to Microsoft REST API guidance, you can put this email info inside GET request headers. github.com/Microsoft/api-guidelines/blob/master/… – Gang Peng Aug 17 '16 at 18:01
  • 1
    I would say send the email in post data. – Anthony Russell Sep 16 '16 at 18:56
2

As pointed out by Jonah B, it is usually impossible to keep all the "request line" components clean.

There is a much safer technique : do not use the PII in the request, but instead use a mapped value for it.

So instead of /customers?email=foo@bar.com you would, for example, have /customers?email=a4kl3delmze, where a4kl3delmze is randomly generated by the server upon creation. Using a value like the hash of the email could work as well.

The point being : the parameter value is mapped to the email in the database, so you can still execute your biz-logic but you don't transfer the email string value with your requests

1

There are very likely other services acting as proxies- client or server-side- or load balancers in this architecture. These handle dispatching requests across a pool of Tomcats, any one of which may be unable to serve requests due to deployment or maintenance or other reason.

All of those services will have similar access_logs, either written to log files or written to local system logging services, which may themselves get shipped to 3rd party logging aggregators or backed up to backup services or any number of other places.

It is not possible in general to keep the components of the "request line"- method, URI, querystring, HTTP version- out of all kinds of durable storage.

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.