With that switch, I moved from dealing with secure programming from a mostly theoretical (as in auditor) to actually using that theoretical knowledge and applying it practically.
The project that I was tasked involved making a change to a web-based application; this in turn required a change to an API that we provide to third-party vendors (yes, we use the same API that everyone else does).
Basically, the issue I'm having is how do I get information back to the API user when the asynchronous system rejects the data provided.
One of the basics of secure programming is for data to be validated before processing; also, functions are expected to return success/failure codes.
In this particular case, the API will not be able to provide information to the caller if the backend rejects the input data.
In discussing this situation to a senior member of my group, he provided a solution that I didn't even think of at all: state in the API documentation that the caller should verify that the parameter data they're providing is correct; and any incorrect data will be rejected logged by the backend system.
Some will argue that using the documentation is a cop out; that it's more of a liability protection than doing it in a "secure programming" manner.
However, I would argue that the documentation should be part of the "secure programming" practice because it makes it clear to everyone what they should expect from the application.
Cross-posted from Home+Power