Orbit-db security, how to prevent illicit docstore updates

408 Views Asked by At

I have a specific use case for orbit-db but I am a bit fuzzy about a certain security implication.

I'm developing a web app where a user logs in through a Tronweb wallet account.
People can post questions, whereas other people can answer them and get paid for it.
In order to do so, I add the public key of the respondent to the question and save it to Orbit db.

Now it is my understanding that default access to any orbit-db instance is given to the app (identity) that creates it per default, or you can add custom access controllers. Let's say, if I want to create a db to manage tags, I could create an identity based on my own tronlink account and require a login to create those tags. Nobody else would be able to access that db.

Now what I am a bit fuzzy about is what happens when:

An OP creates a question, and a respondent registers an answer.
When the OP accepts the answer, and payment through the Tronlink plugin will be executed.
But since OrbitDB can run without a server (i.e. p2p based on a local IPFS node), what prevents anybody to set a breakpoint in the client-side Javascript code, get a handle to the db instance, and execute an update call to update the respondent's address locally in that question document, after which it will be synced to other nodes?
I store the public key of the respondent in orbitdb, but the transaction is still confirmed by the OP through Tronlink wallet plugin of course. But still, you cannot assume all users to check it every time.

Since there is no server involved, I don't see how you can prevent corruption of the db client-side by unwanted parties.
Could you enlighten? Let me know if my question is not clear.

1

There are 1 best solutions below

5
On

what prevents anybody to set a breakpoint in the client-side Javascript code, get a handle to the db instance, and execute an update call to update the respondent's address locally in that question document

Nothing.

after which it will be synced to other nodes?

This is what makes OrbitDB secure. Each document that is synced to a new node, needs to pass through the validator function of this node. So, honest (the ones that have a correct AccessController) nodes will filter out malicious changes.


What that means? A node can be "corrupted" but it can't "corrupt" other nodes in the network.