5. I
nclude business logic in design reviews:
when you perform secure design
reviews, ensure that you are evaluating business logic and end to end API
flows for susceptibility to abuse. When building or integrating APIs, you
must also consider how functionality might be misused or abused.
Identifying, triaging, mitigating, and remediating vulnerabilities in your own
custom APIs is different from patching vulnerabilities in vendor supplied
software. Security issues may also only manifest themselves in a complete
system after code has been built and deployed, which is where an
organization must stress fast detection and response, not just
pre-deployment analysis.
API documentation
The top 3 recommendations for secure design and development include:
1. Use machine formats like OpenAPI Specification OAS
2. Repurpose API schema as a basic testing approach and protection approach
3. Have a contingency plan for documentation discrepancies and API drift
API documentation serves a range of security and non-security purposes
throughout the API lifecycle. Documentation is useful for the application and API
teams that are building or integrating APIs. Adequate documentation also provides
benefits to a range of activities including design reviews, security testing,
operations, and protection. API documentation should be created in machine
formats such as OAS for REST APIs. The machine formats allow for auto-generation
of documentation as part of design and mocking, and they are also parsable by
other testing and protection tooling. Like all forms of documentation though, teams
inevitably neglect to document APIs or new functionality as they iterate. This reality
of API documentation process leads to a type of environment drift, or API drift, that
leaves massive gaps in your API inventory and security posture.
Best practices for API documentation include:
1.
Dostları ilə paylaş: |