This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Defense in depth"
| Line 3: | Line 3: | ||
{{Template:Stub}} | {{Template:Stub}} | ||
| − | == | + | ==Overview== |
| + | |||
| + | The principle of defense in depth suggests that where one control would be reasonable, more controls that approach risks in different fashions are better. Controls, when used in depth, can make severe vulnerabilities extraordinarily difficult to exploit and thus unlikely to occur. | ||
| + | |||
| + | With secure coding, this may take the form of tier-based validation, centralized auditing controls, and requiring users to be logged on all pages. | ||
| + | |||
| + | For example, a flawed administrative interface is unlikely to be vulnerable to anonymous attack if it correctly gates access to production management networks, checks for administrative user authorization, and logs all access. | ||
[[Category:Principle]] | [[Category:Principle]] | ||
Revision as of 14:50, 14 June 2006
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.
Overview
The principle of defense in depth suggests that where one control would be reasonable, more controls that approach risks in different fashions are better. Controls, when used in depth, can make severe vulnerabilities extraordinarily difficult to exploit and thus unlikely to occur.
With secure coding, this may take the form of tier-based validation, centralized auditing controls, and requiring users to be logged on all pages.
For example, a flawed administrative interface is unlikely to be vulnerable to anonymous attack if it correctly gates access to production management networks, checks for administrative user authorization, and logs all access.
