About These Questions

When a code review is requested by emailing securitysupport@illinois.edu, the Cybersecurity team will typically start by discussing these questions with lead and senior software developers who contributed to the code.

These questions are inspired by the Open Web Application Security Project (OWASP) API Security Top Ten - which is a version of the Top Ten targeted specifically to API security.

The top ten risks are recalculated every few years based on combined data on actual vulnerabilities. The project is broadly accepted as an authority on cybersecurity risks in custom code.

Code Security Review OWASP Example Questions

API1:2019 Broken Object Level Authorization

APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue.

• How is object level authorization enforced?
• What processes does the team use to ensure authorization is applied consistently?

API2:2019 Broken User Authentication

Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently.

• What does the API use for authentication?
• After how long does each client session expire?
• Is any data transmitted in clear text?
• Is key management and key rotation setup?
• Are any old or weak cryptographic algorithms used either by default or in older code?
• Was any encryption custom developed for this application?

API3:2019 Excessive Data Exposure

Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.

• How are new fields reviewed before being exposed to clients through the API?
• How much trust is required from the API client to do the right thing with the available data?
• Is too much data exposed to some API clients?
• Does the API store passwords, credit card numbers, social security numbers, grades or other sensitive information?

API4:2019 Lack of Resources & Rate Limiting

Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user.

• How does the API handle request size limits?
• Do the API endpoints support result paging?
• Is the service or gateway configured to rate limit requests per client?
• What kind of load testing has been performed?
• Is a baseline of expected API traffic known? If so, is monitoring or a dashboard setup with awareness of the baseline? This can be valuable in detecting security incidents early.

API5:2019 Broken Function Level Authorization

Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws.

• What does the API use for authorization?
• Are all development team members training in proper usage of the authorization system?
• Does the unit, integration or manual test suite test for authorization mistakes?
• Are sensitive actions in the API reversible?

API6:2019 Mass Assignment

Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.

• Does the unit, integration or manual test suite test for unwanted assignment to internal or read-only API object properties?

API7:2019 Security Misconfiguration

Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.

• Where is the application hosted, and who maintains the server?
• Are the server admins aware of cybersecurity best practices for the systems they manage?
• Are any cloud or appliance security dashboards available enabled and configured?
• Are any Cross-Origin Resource Sharing (CORS) headers set on systems that serve the APIs? If so, are they restricted to appropriate domains?

API8:2019 Injection

Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

• Do your developers use parametrization for database access?
• Is external data sanitized before being passed to the database?
• Does the application enforce reasonable length limits on all external input?
• What database connectors does the application use?
• Do all database connectors in use support parametrization?
• Do the developers know how to apply parametrization properly?
• Is the database connection code managed by an Object-Relation Model (ORM) or a query framework?
• If so, does the ORM or query framework automatically enforce parameterization?

API9:2019 Improper Assets Management

APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.

• If a component or the product itself is identified as vulnerable, how can installed instances be inventoried for attack surface anaylsis and upgrade?
• Is any automated installation inventory in use? (i.e. inventory managed by Ansible, Puppet, or Chef?)
• How are versions of external components tracked?
• What processes are in place to update external components as part of the software lifecycle?
• Does the API have any debug endpoints? How are any debug endpoints protected?

API10:2019 Insufficient Logging & Monitoring

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data.

• Are all security events logged?
• Are security logs delivered to a dashboard available to all DevOps team members?

Security events include:

• Authentication and authorization events
• Login attempt
• Privilege escalation
• Permissions modifications
• Attempts (success or failed) to view, modify or delete sensitive information.
• Attempts (success or failed) to view, modify or delete profile information which could lead to a security compromise (i.e. harvesting or changing an email address is a first step in many attack scenarios.)