Fail securely

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

Jump to: navigation, search

[ african weaving patterns ] the australian flag information [ asian football federation ] [ australian organ donor ] [ what is happening in sudan africa ] [ automotive trim screws ] [ asia movie ] [ asian ignition remix ] [ superannuation australian government ] [ asian super idols ] [ caucasian mountain dogs ] [ asian female los angeles ] [ meryls role in out of africa ] domain [ automobile car financing purchase used ] [ cheap tickets australia ] [ multiple endocrine neoplasias ] [ cheap australian web hosting ] [ avg antivirus pro v7.0.203 ] [ mail guardian newspaper south africa ] [ akedemi fantasia ] [ linux antivirus review ] [ asian gift ideas ] [ town maps australia ] [ hal home automation software ] [ vodafone australia mobiles ] link [ auto hunters ] sitemap [ australian history facts ] [ napa auto parts canton ] [ africa forced removal south ] [ computer wholesalers in south africa ] asian food grocer [ top rated antivirus software 2005 ] [ story of anastasia romanov ] [ dod antivirus download ] [ welsh cobs australia ] [ african america prom updos ] [ witsands south africa ] links [ nod32 antivirus reviews ] [ antivirus servers ] [ africa against aids current fight in news ] [ map of african mountains ] [ caucasians in hawaii ] [ african masks com ] [ housecall ] [ avg antivirus new ]

This is a principle or a set of principles. To view all principles, please see the Principle Category page.

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.


Handling errors securely is a key aspect of secure coding. There are two types of errors that deserve special attention. The first is exceptions that occur in the processing of a security control itself. It's important that these exceptions do not enable behavior that the countermeasure would normally not allow. As a developer, you should consider that there are generally three possible outcomes from a security mechanism:

  • allow the operation
  • disallow the operation
  • exception

In general, you should design your security mechanism so that a failure will follow the same execution path as disallowing the operation. For example, security methods like isAuthorized(), isAuthenticated(), and validate() should all return false if there is an exception during processing. If security controls can throw exceptions, they must be very clear about exactly what that condition means.

The other type of security-relevant exception is in code that is not part of a security control. These exceptions are security-relevant if they affect whether the application properly invokes the control. An exception might cause a security method not to be invoked when it should, or it might affect the initialization of variables used in the security control.



isAdmin = true; 
try { 
  isAdmin = isUserInRole( “Administrator” ); 
catch (Exception ex)

If codeWhichMayFail() fails, the user is an admin by default. This is obviously a security risk.

Related Vulnerabilities

Related Controls