Secure Coding with DDD

Domain-Driven Design for Secure Code


With the ever-growing software ecosystem, attributes for successful product are performance, security, maintainability, and usability. When it comes to delivering product the priorities are quality assurance, time to market and it need to stay within budget. The security-related tasks in the backlog keep getting lower priority compared to the business functionality. After all, time is tight, and it doesn’t matter if the system is secure if the features the users need are not there. 

With the traditional approach, the security review identifies vulnerabilities that are severe and must be addressed before deploying to production. This sets your project back by a few weeks, or maybe even months eventually resulting in lost revenue. To create secure software efficiently and effortlessly, it is important to focus more on design rather than security as an afterthought.


Design considerations


While writing code, careful attention is applied to represent business logic, which is the functionality that makes the product unique, build code explicitly and easy to maintain. While modeling our business domain, considerable amount of time is spent in evolving and refining domain model and how it will be represented in code. For example, consider aspects such as readability or performance, based on preferences, decide on how we are going to write the code in that statement. Based on experience and knowledge to actively make choices appropriate to the software built. These choices are part of what determines the design of the software.

The design is the guiding principle for how a system is built and is applicable on all levels, from code to architecture. The activities that involve conscious decision-making involved in software development are an integral part of the design process. That means that domain models, software modules, APIs, and design patterns are just as important to the design of the software as are field declarations, if statements, hash tables, and method declarations. All of these contribute to the stability of the design.


Domain-Driven Design


The design approach recommended for building complex software is Domain-Driven Design(DDD). It is an approach which centres the development on programming a domain model that has a rich understanding of the processes and rules of a domain, for e.g. e-commerce checkout feature.  Focus is on the domain which is a way of breaking the application into smaller areas according to their business rules. 

The building blocks for DDD define a number of high-level concepts that can be used in conjunction with one another to create and modify domain models. 

  • Entity: Entities are objects meant to be unique within the domain and sis achieved by using one or more proprieties to identify a given entity. It is crucial to identify information in a consistent manner to coordinate and control behaviour to maintain security in application. 
  • Value Objects: They unlike entities don’t have an identity, so only their properties can be used to distinguish between two instances. In DDD, value-object are immutable and conceptual whole. It ensure centralized validation of the information, thus reduce security bug in application. 
  • Data Events: An object that is used to record a discrete event related to model activity within the system. While all events within the system could be tracked, a domain event is only created for event types which the domain experts care about and it ensure data integrity. 
  • Aggregates: A DDD aggregate is a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items, these will be separate objects, but it’s useful to treat the order (together with its line items) as a single aggregate. It protect modification of information in true invariants in trusted boundary.
  • Repositories: It is a authorization service that uses a global interface to provide access to all entities and value objects that are within a particular aggregate collection. 


Key design principles


  • Immutability: Security problems involving data integrity and availability could lead to an adverse effect to overall business. While designing value objects, you need to decide whether they should be mutable or immutable. It will keep the data consistent during its entire life cycle and ensures that data is obtainable at the expected level of performance in a system.
  • Failing fast: Security problems involving illegal input and state can be minimized with appropriate software design practices of preconditions and Design by Contract. A contract specifies the preconditions that are required for the method to work as intended, and it specifies the postconditions for how the object will have changed after the method is completed. Design by Contract avoids lots of those situations that give rise to vulnerabilities. Secure handling to terminate the job as soon as it becomes clear that the preconditions aren’t met.
  • Validation: A major security problem is not validating of user input. Ensure validation is implemented both in the client and server side and also while data from the from database. The list presented here also suggests a good order in which to do the different kinds of validation. The order is from the quickest filters, cheapest in performance terms, to the more complicated check.

Types of validation:  

      • Origin —Is the data from a legitimate sender?
      • Size —Is it within the expected limit?
      • Lexical content —Does it contain the right characters and encoding?
      • Syntax —Is it in the right format?
      • Semantics —Does the data make sense?




With design focused software development, security can become a natural part of the development process instead of being perceived as a forced requirement.

  • Software design is central to the interest and competence of most developers, which makes secure by design concepts easy to adapt.
  • By focusing on design, business and security concerns gain equal priority in the view of both business experts and developers.
  • By choosing good design constructs, non-security experts are able to write secure code.
  • By focusing on the domain, many security bugs are solved implicitly.

The post Secure Coding with DDD appeared first on Security Intelligence.