Obfuscate ResourceIDs

[StefanSchubert]

Providing internal objects database IDs as resource IDs are a potential security risk.
To minimize this risk all ResourceIDs that will be published to the clients needs to be obfuscated, such that a client won't be able to access a different object just by incrementing the ID. In addition any invalid ID provided by the client should be logged in a special fraud-detection log with the clients IP.

[StefanSchubert]

This involves converting the long id to string in the To-Objects, and to adapt the mapper for the required conversion step.

[StefanSchubert]

Would this really tighten the security? In which cases?

• If someone hacks onto the 2nd tier node and gains direct access from the data base, this counter measure does not matter at all.
• So the attack vector would be through the API.
  • Through sloppy programming (by not checking if the object belongs to the user)
  • If the JWT Token security failed. Algorithm has been hacked
  • If TLS Layer has been hacked and a JWT Token has been captures through a man in the middle access. Because of the ownership check this could damage the data of the user in question.

Though I currently doubt that the possible attack vectors would happen and that an open science project would not be of any interest to a hacker, this measure would tighten the security level an additional bit.