12 Guidance in legacy code

This chapter offers practical guidance for applying secure-by-design principles to legacy codebases. It starts by urging teams to identify bounded contexts and semantic boundaries so that domain primitives can be introduced where they make the most sense. The authors outline common smells that frequently appear in older systems—ambiguous parameters, unchecked logging, defensive code constructs, misapplied DRY, insufficient validation in domain types, and a bias toward only “good path” tests—and show how to prioritize and address them without disrupting delivery.

Key refactorings revolve around replacing ambiguous parameters with explicit domain primitives or secure entities and choosing a fitting migration strategy: a direct swap in smaller codebases, a discovery-first approach to surface data-quality issues, or a new API that enables incremental adoption. The chapter warns against logging unchecked strings and highlights risks like data leakage and second-order injection, as well as subtle leaks via implicit toString usage or reflection; remedies include explicit accessors and treating sensitive values as read-once. It challenges defensive coding patterns—scattered null/format checks and overuse of Optional—advocating clear contracts and centralized validation. On DRY, it emphasizes deduplicating ideas, not text, to avoid overcoupled “util” dependencies, and it teaches how to spot both false positives and false negatives in duplication.

Further guidance strengthens domain types with strict, domain-informed invariants and elevates testing beyond normal and boundary cases to include invalid, extreme, and dependency-failure scenarios. The authors caution against partial domain primitives that miss key context, illustrating with money amounts that must carry currency to form a conceptual whole and prevent invalid operations. Throughout, the chapter balances rigor with pragmatism: introduce types where semantics are stable, expect data-quality issues to surface, and choose a migration path that fits the codebase size and team structure to steadily improve security by design in legacy systems.

• Introducing domain primitives should be done at the semantic boundary of your context.
  
• Ambiguous parameters in APIs are a common source of security bugs.
  
• You should be on the lookout for ambiguous parameters when reading code, and address those using the direct approach, the discovery approach, or the new API approach.
  
• Never log unchecked user input because it opens up the risk of second-order injection attacks.
  
• Limit the number of times a sensitive value can be accessed because it allows you to detect unintentional access.
  
• Use explicit accessor methods for data that you want to log. Otherwise, new fields can end up in logs by accident.
  
• Because defensive code constructs can be harmful, clarify those using contracts and domain primitives.
  
• The DRY principle (Don’t Repeat Yourself) is about repeated representation of knowledge, not about repeated text.
  
• Trying to reduce repeated text that isn’t repeated knowledge can cause unnecessary dependencies.
  
• Failing to reduce repeated knowledge because the text differs can cause vulnerable inconsistencies.
  
• Tests reveal possible weaknesses in your code, and you should look for invalid and extreme input tests.
  
• Ensure that your domain primitives encompass an entire conceptual whole.
  
• Be on the lookout for domain types lacking proper validation and address these with domain primitives and secure entities.
  

FAQ