Implement interface contracts

Revision as of 05:30, 26 May 2009 by Deleted user (Talk | contribs)

Jump to: navigation, search

[ 3 australian formula ] [ auto cheat city grand thief vice ] notron antivirus webmap [ automobile vinyl top installation ] [ australian standard classification of occupation ] [ asia pacific region facts ] symantec antivirus corporate edition v 10.0 [ disable norton antivirus 2004 ] [ dirt cheap auto insurance michigan ] [ aids in kenya africa ] [ the first african american basketball player ] [ australia pajero ] links [ australian meals made through the gold rush ] [ asian grocery denver ] [ south africa safaries ] [ antivirus filtering ] [ pop pro up winantivirus ] [ automation form greibach normal theory ] [ african child labor picture images ] [ australia land tours ] [ price on automobile glass ] [ home and away australian soap opera ] [ auto body shop in minnesota ] [ left eye autopsy photo ] [ asian woman fashion magazine ] [ ink cartridge australia ] index [ nortan antivirus 2005 serial key ] [ asian avenue graphic ] [ australian army history grants ] [ voluntary euthanasia ] [ avant antivirus ] [ asiatic carpets ] [ south african safari club ] australia inc lottery lotto programme [ african american civil movement right woman ] sitemap [ types of antivirus software ] webmap [ auction auto public wyoming ] [ automotive carpet custom ] [ auto+trader ] [ african ibo masks ] link [ australian council midwifery ] [ australia divorce laws ]



  • Provide unit-level semantic input validation.
  • Identify reliability errors in a structured way at the earliest point in time.


  • Implementer


  • As needed; generally as functions or methods are modified.

Interface contracts are also commonly known as assertions. They can be a formidable tool for preventing security problems - particularly if applied consistently, and rigorously.

In many application development processes, interface contracts are not enabled in production software. They are removed by habit in order to improve efficiency. If the efficiency impact is nominal for the project, CLASP strongly recommends leaving such checks in the code for the sake of security.

Otherwise, checks of security critical parameters should be implemented using a permanent mechanism, such as code directly at the top of the function, as discussed in activities below.

Implement validation and error handling on function or method inputs

For each method or function visible outside its compilation unit, specify in code what the expectations are for valid input values. One should validate that each input variable has a valid value in and of itself, and should determine validity in relation to other inputs. Validation checks should contain no side effects. Failures should be handled as specified in design. See CLASP Resource B for the concept on input validation.

Input variables should not be constrained to parameters. Any variable read by the function or method should be considered an input variable - including global variables, and class and method variables. Note that some interface contract facilities will allow specifying invariants for an entire class - i.e., things that must always be true about class data before and after each method invocation - once.

Implement validation on function or method outputs

Perform the same validation between relationships before exiting a function or method. Output specifications are meant to provide a clear behavioral specification to calling code to prevent accidental misuse.

Generally, output validation code is most useful in implementation. It is reasonable to disable such code for deployment or even use pseudo-code if absolutely necessary.