API Security Policy

1. Purpose

The purpose of this policy is to inform all DefectDojo employees and external parties with access to DefectDojo equipment, systems, or networks (DefectDojo Staff) of their obligations with regards to the security of Application Programming Interfaces (APIs) of all systems, networks, IT assets, and licensed software owned, operated, or used by DefectDojo.

2. Scope

API security as applied to information security and the confidentiality, integrity, and availability of company-owned, processed, stored, and transmitted information via APIs.

3. Compliance

3.1 Compliance Measurement

The Information Security Management team will verify compliance to this document through various methods, including but not limited to business tool reports, internal and external audits, and feedback to the document owner.

3.2 Exceptions

Any exception to this document must be reviewed and approved in advance by the Management Review Team.

3.3 Non-Compliance

Any DefectDojo Staff found to have violated this document may be subject to disciplinary action, up to and including termination of employment.

3.4 Continual Improvement

This document is updated and reviewed as part of the continual improvement and process.

4. Requirements

4.1 Authentication

• Ensure all possible flows to authenticate to the API (mobile/web/deep links implementing one-click authentication/etc.) are known and documented.
• Treat all credential recovery/forget password endpoints as login endpoints regarding brute force, rate limiting, and lockout protection.
• Enforce authentication through a web browser whenever possible.
• Enable Multi-Factor Authentication (MFA) where technically possible.
• Implement brute-force prevention mechanisms to mitigate credential stuffing, dictionary attacks, and brute-force attacks on authentication endpoints.
• Implement an account lockout/captcha mechanism to prevent brute-force against specific users.
• Implement weak-password checks.
• Do not use API keys for user authentication.
• Do not allow login with sensitive accounts to any front-end user interface.
• Do not use the same authentication solution used internally for unsecured access.

4.2 Authorization

• Implement a proper authorization mechanism that relies on user policies and hierarchy.
• Use authorization checks to verify that the logged-in user has access to perform requested actions on records.
• Write tests to evaluate the authorization mechanism and do not deploy changes that break tests.

4.2.1 Function Level Authorization

• Deny all access by default, requiring explicit grants to specific roles for access to every function.
• Review API endpoints against function-level authorization flaws, considering business logic and group hierarchy.
• Ensure all administrative controllers inherit from an abstract administrative controller implementing authorization checks.
• Ensure administrative functions in regular controllers implement authorization checks.

4.3 Create and Update an API Inventory

• Maintain an inventory of all API hosts and environments (production, staging, development) per the Asset Management Policy.
• Document roles with network access to the host and the API version.
• Inventory integrated services and their roles.
• Make API documentation available to authorized users.
• Automate documentation generation using standards like Swagger/OpenAPI.
• Include documentation builds in the CI/CD pipeline.

4.4 Implement Strong Encryption Mechanisms

• Encrypt data transfer between API servers and clients to prevent interception. See the Cryptographic Controls Policy for guidance.

4.5 Use Quotas and Throttling to Limit Requests

• Establish quotas and thresholds to prevent denial-of-service attacks by limiting the number of requests a client can submit over a time period.

4.6 API Scanner for Vulnerabilities

• Deploy scanning solutions to automatically discover known vulnerabilities in applications.

4.7 Data Protection

• Do not use production data in non-production APIs; if unavoidable, apply the same security measures.
• Review API responses to ensure only legitimate data is returned.
• Avoid generic methods like to_json() or to_string().
• Classify sensitive/PII data and review API calls for potential security issues.
• Implement schema-based response validation for all API methods, including errors.

4.7.1 Binding client-provided data

• Do not automatically bind client input into code variables or objects; use input validation/sanitization techniques.
• Allowlist only properties the client must update.
• Denylist properties clients must not access.
• Explicitly define and enforce schemas for input payloads where applicable.

4.8 Resources and Rate-Limiting

• Limit how often a client can call the API within a defined timeframe.
• Notify the client when limits are exceeded, including limit and reset time.
• Validate query strings and request bodies, controlling the number of returned records.
• Enforce minimum and maximum data sizes on all parameters and payloads.

4.9 Security Configuration

• Use a repeatable hardening process for a locked-down API environment.
• Review and update configurations across the API stack (orchestration files, components, cloud services).
• Use secure communication for API interactions accessing static assets.
• Continuously assess the effectiveness of configurations.
• Perform risk analysis when upgrading APIs with security improvements.
• Use external protection measures (e.g., API security firewalls).
• Prevent exception traces and sensitive information from being sent to attackers.
• Implement strict CORS policies for browser-based clients.
• Separate data from commands and queries.
• Use a single, trusted library for data validation.
• Validate, filter, and sanitize all client-provided or integrated system data.
• Escape special characters using the correct syntax.
• Limit the number of returned records.
• Enforce data types and strict patterns for string parameters.

4.10 Logging and Monitoring

• Log all access and use of APIs according to the Logging and Monitoring Policy.

5. Relevant Documents

• Access Control Policy
• Asset Management Policy
• Data Classification Policy
• Information Security Policy
• Logging and Monitoring Policy