Cybersecurity, Code Risk Discussion Questions

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) Top Ten Web Application Security Risks. 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

Broken Access Control (A01:2025)

• Are the authentication and authorization mechanisms properly applied to every resource?
• How is this maintained as the code changes over time?
• Can an outside actor trick a user into triggering a sensitive action in the application?
• Are sensitive actions in the application reversible?
• Are sensitive actions in the application logged?

Broken Access Control - Server-Side Request Forgery (SSRF) (A01:2025)

From Network layer

• To reduce the impact of SSRF, is remote resource access functionality segmented into separate networks?
• What firewall policies or network access control rules block unexpected network traffic?
• Who reviews firewall rules for existing applications, and what reminders exist to ensure the review happens and any required changes are applied?
• Are all accepted and blocked network flows on firewalls logged (see A09:2021-Security Logging and Monitoring Failures)?

From Application layer

• Is your application built on a web framework with a dedicated URL routing component?

• Is raw unmodified output from any code library or subsystem sent directly to clients?

• Are HTTP redirections disabled?

• Are you aware of the URL consistency to avoid attacks such as DNS rebinding and “time of check, time of use” (TOCTOU) race conditions?

• What percentage of your web application's authentication, authorization and URL routing is custom code (vs handled by a dedicated framework or library)?

• How are your web applications and services isolated from each-other?

• How sensitive is the functionality and data of those services?

• Are audiences with incompatible needs using shared components? (Students, Faculty, IT Professionals)

• Are any services running next to each-other causing unacceptable risks to each-other?

• Who can login to your web facing systems without going through the central campus authentication solution (Shibboleth/Azure Active Directory)?

• Are such users required to use a Virtual Private Network and Multi-factor Authentication?

Security Misconfiguration (A02:2025)

• Where is the application hosted, and who maintains the server?
• Are the server administrators aware of cybersecurity best practices for the systems they manage?

Software Supply Chain Failures (A03:2025)

• How are versions of external components tracked?
• What processes are in place to update external components as part of the software life cycle?
• If using GitHub, has your team configured Dependabot security alerts
• Are you scanning your environment with Qualys?
• Are End-Of-Life dates documented, based on known dependencies, in all projects?

Cryptographic Failures (A04:2025)

• Is any data transmitted in clear text?
• Are any old or weak cryptographic algorithms used either by default or in older code?
• Key Management
• Are default cryptographic keys in use?
• Are weak cryptographic keys generated or re-used?
• Is proper key management or rotation missing?
• Is encryption not enforced, e.g. are any user agent (browser) security directives or headers missing?
• Does the user agent (client app) not verify if the received server certificate is valid?
• Does the application store passwords, credit card numbers, social security numbers, grades or other sensitive information?
• If so, is appropriate encryption being used?
• If so, is the data storage environment secured to campus IT standards for sensitive information?
• Was any encryption custom developed for this application?
• Has the impact of quantum decryption been considered for this application?

Injection (A05:2025)

• Is parametrization used for database access?
• Is user data sanitized before being passed to the database?
• Does the application enforce reasonable length limits on all user 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 parametrization?

Injection - Cross Site Scripting (XSS)

• What are your sources of user input to the application?
• Are validation rules enforced for every input?
• How are user inputs sanitized before displaying them back to other users?

Insecure Design (A06:2025)

• Note: Insecure design focuses on risks related to design and architectural flaws, with a call for more use of threat modeling, secure design patterns, and reference architectures.
• Have you documented your software development life cycle?
• Have you established, and are you using, a library of secure design patterns or paved-road ready to use components?
• Threat Models
• Are threat models documented for critical authentication, access control, business logic, and key flows?
• A threat model typically contains:
  • Assessment of Scope (Often the topic of the current sprint)
  • What can go wrong?
  • Risk management strategy
  • Assessment (How satisfied is the team with this threat model?)
• Are security controls described by user stories?
• Have you written unit and integration tests to validate that critical flows are resistant to the threat model?
• Have you compiled use-cases and misuse-cases for each tier of your application?
• Have you limited resource consumption by user or service?

Identification and Authentication Failures (A07:2025)

• What does your application use for authentication?
• What does your application use for authorization?
• After how long does each user session expire?

Software Data Integrity Failures (A08:2025)

• Are digital signatures or similar mechanisms used to verify the software or data is from the expected source and has not been altered?
• Are your libraries and dependencies, such as npm or Maven, consuming trusted repositories?
• Are you hosting an internal repository?
• Is your team's process for vetting new software dependencies documented?
• Does your development pipeline include an automated step to verify the components do not contain known vulnerabilities?
• Is there an established and consistent review process for coding and configuration changes?
• How is your CI/CD pipeline protected?

Software Data Integrity Failures - Insecure Deserialization

• Is user session information serialized and shared between the server and client?
• Are serialized data objects accepted from untrusted sources?
• How are deserialized objects verified before being trusted?
• What integrity checks prevent tampering or replay of serialized data?

Security Logging and Monitoring Failures (A09:2025)

• Are all security events logged?
• How long are logs containing security events retained?
• How are sensitive transactions audited?
• What automated alerts exist that could indicate suspicious activity?
• Does the team have a documented incident response plan?

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 (harvesting or changing an email address is a first step in many attack scenarios)
• For more information see Cybersecurity, Logging Practices for Application Developers

Mishandling of Exceptional Conditions (A10:2025)

Mishandling exceptional conditions in software happens when programs fail to prevent, detect, and respond to unusual and unpredictable situations, which leads to crashes, unexpected behavior, and sometimes vulnerabilities.

• Does the application have a mechanism to ensure that all un-handled exceptions present an acceptable message to end users?
• Is the application configured to ensure that detailed informative error messages with stack traces only reach trusted maintainers (and are not presented to untrusted users)?
• Does the application have a mechanism to ensure that all un-handled exceptions result in a log entry?
• Does the application have a mechanism to ensure that changes in progress (transactions) roll back in the event of an un-recovered exception?
• Are these mechanisms tested for each new release of the application?
• Is the DevOps team trained on solutions to review the application logs, including potentially handling large numbers of similar exceptions?
• Is the DevOps team trained on solutions to setup alerts for log events that the team wants to investigate further?
• This seems like a good place for a shameless plug for the Campus Splunk Service.
• Teams can benefit from shared training and techniques. Are the mechanisms discussed here aligned with the DevOps team's most frequent collaborators.