Instruction data

This attack vector is the first we have to secure, and it is also the simplest. Securing the instruction data input means making sure that both the deserialization and business logic can handle all possible inputs. When we use Borsh or bytemuck as deserializers, any bit pattern which does not conform to our schema will result in an error. This is precisely what we want. As a corollary, you should be careful when implementing custom deserialization logic. Borsh and the tools provided by bonfida-utils should be enough for your use-case.

The harder part is thinking about the business logic itself. You should think about what kind of values your program should allow as input. Be as restrictive as possible. If a user reports that their own use-case for your product is not handled due to these restrictions, you can update your program. If your program's state / assets are compromised, you can still patch the vulnerability, but the incident will probably have cost you.

To secure your program's business logic, we recommend a combination of unit and integration testing. It can be very useful to use coverage testing tools to make sure that your business logic is sound for every edge case. We will discuss testing in a later section.