An API is a contract between a caller and a callee. The most common forms of API abuse are caused by the caller failing to honor its end of this contract. For example, if a program fails to call chdir() after calling chroot(), it violates the contract that specifies how to change the active root directory in a secure fashion. Another good example of library abuse is expecting the callee to return trustworthy DNS information to the caller. In this case, the caller abuses the callee API by making certain assumptions about its behavior (that the return value can be used for authentication purposes). One can also violate the caller-callee contract from the other side. For example, if a coder subclasses SecureRandom and returns a non-random value, the contract is violated.
SQL Bad Practices: Direct Update
Direct Open SQL write operations are also error prone and can cause unexpected system behavior. Some of the issues to watch out for in SAP include:
- SAP recommends using 'update bundling' techniques to ensure data integrity within an SAP LUW (logical unit of work) that may span multiple database LUWs. Direct modifications to table entries without update bundling may leave the SAP transaction in an inconsistent state.
- Direct Open SQL write operations only set database level locks and bypass the SAP application locks. This may lead to deadlocks and corrupted data.
- Direct Open SQL write operations bypass SAP authorization checks within the application program.
- When standard mechanisms are used to write table entries, edit checks, audit trails, dependent updates (like change documents, for example) are all correctly performed. This is not the case when Direct Open SQL write operations are used.