In Secure Programming, the Documentation Matters Too

Thursday, June 28, 2012

Keith Mendoza


I got a new job, I moved from the IFE industry to the payment processing industry.

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

Possibly Related Articles:
Policy Enterprise Security Application Security Web Application Security Documentation Secure Coding API Programming Input Validation
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.

Most Liked