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-C | Medium | Unlikely | High | P2 | L3 |
API01-C | High | Likely | High | P9 | L2 |
API02-C | High | Likely | High | P9 | L2 |
API03-C | Medium | Unlikely | Medium | P4 | L3 |
API04-C | Medium | Unlikely | Medium | P4 | L3 |
API05-C | High | Probable | Medium | P12 | L1 |
API07-C | Medium | Unlikely | Medium | P4 | L3 |
API09-C | Low | Unlikely | High | P1 | L3 |
API10-C | Medium | Likely | High | P12 | L1 |
4 Comments
Chris Newman
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:
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:
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.
Robert Seacord
seems like a reasonable recommendation; possibly difficult to enforce. i'll try to add something.
Robert Seacord
OK, stubbed out as API02-C. APIs should have security options enabled by default
Volker Erben
only for completeness: In table "Risk Assessment Summary" the items API02-C, API05-C and API10-C are missing. Please correct.