CERT
Skip to end of metadata
Go to start of metadata

Warning

This section is under construction.

Information for Editors
To have a new guideline automatically listed above be sure to label it api and recommendation.

Risk Assessment Summary

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

API00-CMediumUnlikelyHigh

P2

L3

API02-CHighLikelyHigh

P9

L2

API03-CMediumUnlikelyMedium

P4

L3

API04-CMediumUnlikelyMedium

P4

L3

API07-CMediumUnlikelyMedium

P4

L3

API08-CMediumUnlikelyMedium

P4

L3

API09-CLowUnlikelyHigh

P1

L3

 


3 Comments

  1. How does one suggest a new rule? I'd like to suggest API10-C. APIs should have security options enabled by default

    Non-compliant example:

    Non-compliant

    If the caller of this API doesn't understand what the options mean, they will pass 0 or TLS_DEFAULT_OPTIONS and get a connection vulnerable to man-in-the-middle attacks and using old versions of TLS.

    Compliant example:

    Compliant Example

    If the caller of this API doesn't understand the options and passes 0 or TLS_DEFAULT_OPTIONS they will get certificate validation with only the current version of TLS enabled.

    This API design principle can be extended to cover other security properties – for example, having best practice cipher suites enabled by default (something that changes over time) while disabling out-of-favor cipher suites by default. When interface stability is also a design requirement, an interface can meet both goals by providing off-by-default options that produce stable behavior, such as TLS_ENABLE_Y2015_BEST_PRACTICE_CIPHERS_ONLY.

    1. seems like a reasonable recommendation; possibly difficult to enforce.  i'll try to add something.

    2. OK, stubbed out as API02-C. APIs should have security options enabled by default