secure by design - code construct

src: Secure by Design by Dan Bergh Johnsson | Goodreads

Abstract

• Data integrity is about ensuring the consistency and accuracy of data during its entire life cycle.
• Data availability is about ensuring data is obtainable and accessible at the expected level of performance in a system.
• Immutable values are safe to share between threads without locks: no locking, no blocking.
• Immutability solves data availability issues by allowing scalability and no locking between threads.
• Immutability solves data integrity issues by preventing change.
• Contracts are an effective way to clarify the responsibilities of objects and methods.
• It’s better to fail fast in a controlled manner than to risk uncontrolled failures later. Fail fast by checking preconditions early in each method.
• Validation can be broken down into checking origin, data size, lexical content, syntactic format, and semantics.
• Origin checks can be done by checking the origin IP or requiring an access key to counteract DDoS attacks.
• Data size checks can be done both at the system border and at object creation.
• Lexical content checks can be done with a simple regular expression (regexp).
• Syntax format checks might require a parser, which is more expensive in terms of CPU and memory.
• Semantic checks often require looking at the data in the database, such as searching for an entity with a specific ID.
• Earlier steps in the validation order are more economical to perform and protect the later, more expensive steps. If early checks fail, later steps can be skipped.

Problems area addressed:

• immutability: Security problems involving data integrity and availability
  • Immutable objects are safe to share between threads and open up high data availability, whereas mutable objects, are designed for change, which can lead to illegal updates and modifications.
• failing fast: Security problems involving illegal input and state
  • It’s much better to stop bad data or abnormal situations fast than it is to let them slide and wreak security problems later.
  • One way is to uphold invariants in constructors.
• validation: Security problems involving input validation
  • following types of validation, preferably in this order:
    • Origin: Is the data from a legitimate sender?
      • Can use Access Tokens to check legitimate clients
    • Size: Is it reasonably big?
    • Lexical content: Does it contain the right characters and encoding?
    • Syntax: Is the format right?
    • Semantics: Does the data make sense?