I'm trying to apply the principle that data is toxic asset in a system with many services through which this toxic asset must flow.

The system can be abstracted to 3 actors: clients, intermediaries, and (data) sources. Clients will eventually wish to view some sensitive data (think credit card numbers or PI info) that is housed in a secure data source. Intermediaries are the services in between the client and the source, and so must come into contact with this sensitive data, which is the whole problem.

For the purposes of this scheme, I want to assume that the client and the source are secure (not vulnerable to XSS, injection, etc). My goal is to design a scheme that will mitigate the threat of exposing sensitive data from intermediary services. The method of exposure could be anything, but may include disgruntled employees snooping for credit card numbers, or the service accidentally logging them to places that non-privileged admins can access.

There is an additional requirement that the intermediary can restructure the data (otherwise there would be no point to having an intermediary in the middle at all). For example, imagine the following payload coming from a source:

{"credit cards": [
    "type": "visa",
    "number": "1234-5678-9012-3456",
    "expiry": "10-10-2020"

The intermediary, say an HTML-rendering web-server, may wish to embed this credit card number in a specific part of its HTML response to the client.

My first question is does there exist any solution to protecting sensitive data that must flow through a network of microservices from those services themselves?

It seems that given the nature of sensitive data, it would require you to take care to ensure that any services which handle it are "pretty" secure. This makes data not only a toxic asset, but also infectious: as sensitive data proliferates through a web of micro-services, they all must be made bullet-proof.

I think I've come up with a sane way to solve this problem; however, given the constant reassurance that I should not, under any circumstances, roll my own cryptosystem I am less than confident about going with a home-brew solution.

Here is what I've come up with:

In our architecture, we use JWTs to manage user sessions, and so this gives us the ability to transmit extra information along with the user's session token through the system, with some guarantee that nobody has tampered with it.

My solution is for the client to generate a private/public keypair, and have their public key included in their JWT when they sign in. Clients will send the JWT (with their personal public key) through a network of intermediaries where it will eventually wind up at a data source.

From there, simply have the datasource encrypt - on a per-field basis - those fields which are deemed to be "sensitive" or especially toxic. So, from the previous example:

{"credit cards": [
    "type": "visa",
    "number": "hQEMAwbqkJO6To1iAQf/UHf9ymLR8ejY/A1KouFCGoh9gBE71JgiAuQq5CMkuO7XLViDyf941dTUG==",
    "expiry": "10-10-2020"

The intermediary is thus free to embed the number field wherever it likes, and it will never have access to the original value since it doesn't have access to the user's private key.

Of course, the client will then have to be smart enough to decrypt the field using its private key once the intermediary puts it in an arbitrary place in their own response.

My second question is thus, does this seem like a sane scheme to negate the "infectious" quality of toxic data?

Of course, I don't see any points of vulnerability above and beyond standard attacks against whatever encryption and decryption algorithms we choose to use, but that's kind of the whole reason one shouldn't roll their own cryptosystem :)

Thanks for putting up with the long read if you've made it this far!

  • Vulnerabilities aside, this comes across as extremely complex.
    – Steve
    Commented Jul 18, 2017 at 13:55
  • Which aspects seem particularly complex? I certainly agree that per-field encryption is pretty unorthodox; at least in my case, "just the metadata" isn't very sensitive. I suppose it is generally true that complexity thwarts security Commented Jul 18, 2017 at 17:01

1 Answer 1


Why pass toxic data through the intermediaries at all?

These intermediaries, no matter how many, need to have an API endpoint to retrieve the data itself from. Why not expose this endpoint via an API gateway? In order for your source to be secure, it must already be doing checks to see who can access what data. The clients would have the corresponding keys that grant permissions to said data.

Instead of encrypting the data, redact it, and replace it with a reference to where the un-redacted information is stored on the source server. This could take the form of replacing the value with a unique key, that when sent to the source server alongside the secret key will return the toxic data. It could also be a direct reference to the object id.

Think of toxic data as a block of uranium for use in a missile. Do you hide it in a box, and pass it along to every factory that works on the missile, or do you wait till the missile is finished, then retrieve the uranium from the stockpile?

You must log in to answer this question.

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