Is there a difference between secure design patterns and a generic coding guideline from which you can derive a technology specific coding guidline?

Patterns like "authentication", "secure sessions" or "input validation" are secure patterns and should also be adressed within a coding guidline.

So is there a difference or is it just another definition for the same "content"?

2 Answers 2


There are multiple terminology variants around there, so there won't be an absolute answer.

I'd say that "secure design pattern" is an expression which will be used by people who believe that developers are some kind of ape who can achieve Security if made sufficiently obedient to strict formal rules. While "coding guidelines" would be employed by more realistic people who have understood that developers are best cajoled with "empowerment" (and bananas), and may achieve some decent level of security if offered guidance. A really crucial requirement for security is that people understand what they are doing.


The term "security design pattern" usually means a design practice that when applied correctly ensures that a security property holds. For example, the trademark:

A Trademark in computer security is a contract between code that verifies security properties of an object and code that requires that an object have certain security properties. As such it is useful in ensuring secure information flow. In object-oriented languages, trademarking is analogous to signing of data but can often be implemented without cryptography.

So a developer can trademark an object and use information-hiding to ensure that other modules can't forge the trademark. Then a client can be sure that the presence of the trademark (sometimes as simple as instanceof) implies that the property holds at runtime.

For example, the output of an HTML sanitizer and an HTML template that sanitizes all inputs might be trademarked as known-safe HTML. Downstream code could check the trademark to distinguish between content that still needs to be treated with suspicion from that which originated within the system or which has been filtered on entry into the security domain.

By contrast, a coding guideline could be

When you need to verify that a security property, like well-formedness or provenance, holds, either use one of the validator libraries written by our security engineers, or check that the input has a trademark so that you know the property was checked upstream.

The pattern explains how to design an object or module with certain security properties, and the guidelines point clients who require that property at ways to maintain it in their code.

Patterns explain the relationship between invariants and design/API decisions, whereas guidelines establish what practices to use & when so that developers can effectively coordinate their work.

When working in an object-oriented language with weak information hiding, object trademarking is tougher, so a coding guideline might be

Don't forge trademarks or the secure kernel team will hunt you down.

which doesn't advocate the use of a secure design pattern, but when followed improves system security by preventing abuses of language features that violate security contracts.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .