8.1 General Design Principles

GP.1

Minimize Attack Surface: Interfaces, functionality, parameters, services, and protocols
that are not required MUST be disabled on external and SHOULD be disabled on
internal systems.

GP.2

Don’t Trust User Input: Data that has been received from an untrusted source (e.g. a web
browser) MUST generally be mistrusted and therefore strongly validated.

GP.3

Defense-in-Depth: Security SHOULD be implemented based on multiple layers to
compensate for ineffective security controls.

GP.4

Keep Security Settings Adaptable: Security parameterization SHOULD be declared where
possible (= with configuration statements or annotations) instead of programmable (= with program code) where possible.

GP.5

Externalize Security Functions: Security functions SHOULD be externalized (e.g. using an
external authentication system).

GP.6

Keep Security Consistent: Identical security controls (e.g. one within the web frontend and another within an AJAX interface) SHOULD be implemented with the same security
function (= program code) and policy.

GP.7

Use Mature Security Controls: Security relevant program code SHOULD only be
implemented with mature and tested technologies, algorithms and implementations (APIs,
frameworks etc.).

GP.8

Keep Security Testable: Before a new technology (protocol, framework, API, etc.) is being
used in production, it SHOULD be ensured that proper testing procedures and tools exist
for performing security tests on them.

GP.9

Use Secure Defaults: Use secure / safe defaults (e.g. in frameworks) to prevent unintentional security problems.