This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Difference between revisions of "Category:Principle"

Jump to: navigation, search
Line 9: Line 9:
*Fail safely  
*[[Fail safely]]
*Run with least privilege (least privilege)  
*Run with [[least privilege]] (least privilege)  
*Avoid security by obscurity (open design)  
*[[Avoid security by obscurity]] (open design)  
*Use a positive security model (fail safe defaults)(minimize attack surface)  
*Use a [[positive security model]] (fail safe defaults)(minimize attack surface)  
*Apply defense in depth (complete mediation)  
*Apply [[defense in depth]] (complete mediation)  
*Keep security simple (verifiable)(economy of mechanism)  
*[[Keep security simple]] (verifiable)(economy of mechanism)  
*Detect intrusions (compromise recording)  
*[[Detect intrusions]] (compromise recording)  
*Don’t trust infrastructure  
*[[Don’t trust infrastructure]]
*Don’t trust services  
*[[Don’t trust services]]
*Establish secure defaults (psychological acceptability)(secure defaults)  
*[[Establish secure defaults]] (psychological acceptability)(secure defaults)  

Revision as of 22:13, 10 April 2006


A. (Saltzer and Schroeder)(see Section 3)

B. (McGraw)

C. OWASP Guide

Some of the security mechanisms help when you’re implementing these principles. This is just a rough pass that needs some more work. It can’t be done with just a bullet list, you really need more like a paragraph on each of these.

  • Fail safely
    • Error handling
    • Good logic
  • Run with least privilege
    • Access control
  • Avoid security by obscurity
    • Secure configuration files
  • Use a positive security model
    • Input validation
    • Output encoding
    • Access control
  • Apply defense in depth
    • Boundary validation
  • Keep security simple
    • Centralized security mechanisms
  • Detect intrusions(compromise recording)
    • Input validation
    • Authentication
    • Logging
    • Availability protection
  • Don’t trust infrastructure
    • SSL
    • Encrypt sensitive data
    • Prevent injection
  • Don’t trust services
    • SSL, Authentication, Access control, Input validation, error handling, logging, output validation
  • Establish secure defaults (psychological acceptability)(secure defaults)
    • Notify users
    • Secure “out of the box”