Project Puchufy

Source Code Review

,

Purpose

The main goal of conducting a code review is to prevent security vulnerabilities by carefully reviewing the source code before it is released.

It helps ensure:

  • The application protects sensitive data like passwords and personal information.
  • Attackers can’t exploit weak points, such as bad input handling or broken access controls.
  • Code follows secure development practices and compliance standards.

Scope

The scope of the engagement must always be defined by the business before the testing get started. The application owner must provide the list of all URLs, IP addresses that must be included and excluded to avoid impact that may hamper business operations.

This process applies to:

  • New features, bug fixes, and infrastructure code.
  • Any code that interacts with:
  • Users (forms, APIs, login pages)
  • Databases (data storage or retrieval)
  • External services (integrations, APIs)
  • Authentication or access control systems

Even small changes can introduce risks, so every change should be reviewed.

Roles and Responsibilities

RoleResponsibility
DeveloperWrites secure code and provides context during review.
Application Security TesterFocuses on finding vulnerabilities and risk areas.
Lead or Senior Application Security TesterFinal approval and ensures fixes meet security standards.

Tools

Use tools to support manual reviews:

  • Static Analysis Security Testing (SAST)
    • Example: SonarQube, Semgrep, CodeQL
  • Dependency Scanners
    • Example: OWASP Dependency-Check, Snyk
  • Version Control Code Review
    • GitHub Pull Requests, GitLab Merge Requests

Tools help catch common problems, but manual review is still essential.

Security Review Steps

Step 1: Understand the Change

Before reviewing:

  • Read the feature description or bug report.
  • Identify security-sensitive areas, such as:
  • Login or authentication logic
  • Payment processing
  • User data handling
  • External integrations

Step 2: Check Authentication & Access Control

  • Verify authentication logic is correct:
  • Strong password rules
  • Proper session management
  • Multi-factor authentication if required
  • Ensure authorization prevents privilege escalation:
  • Regular users cannot access admin features.
    • Example: /api/user/123 should not expose another user’s data when changed to /api/user/124.

Step 3: Validate and Sanitize Inputs

  • All inputs must be checked and cleaned before use:
  • Web forms
  • API requests
  • File uploads
  • Watch out for:
    • SQL Injection – Unchecked database queries
    • Command Injection – Running unsafe system commands
    • XSS (Cross-Site Scripting) – Injected scripts in pages

Example safe practice:

# BAD - vulnerable to SQL Injection
query = "SELECT * FROM users WHERE id = " + user_input

# GOOD - use prepared statements
query = "SELECT * FROM users WHERE id = ?"
cursor.execute(query, (user_input,))

Step 4: Secure Data Handling

  • Sensitive data must:
    • Not be hardcoded in the codebase (e.g., API keys, passwords).
    • Be encrypted or hashed using strong algorithms (e.g., bcrypt, AES-256).
  • Use secure protocols (HTTPS, TLS 1.2+).
  • Double-check logs and error messages:
  • No personal or sensitive data should appear in logs.
  • Error messages must be generic to avoid revealing system details.

Step 5: Check External Dependencies

  • Review external libraries and APIs:
  • Verify they are up to date.
  • Remove unused or outdated dependencies.
  • Use tools like OWASP Dependency-Check or Snyk to find known vulnerabilities.

Step 6: Test Business Logic

Think like an attacker:

  • Can you skip steps in a workflow to gain an advantage?
    Example: Applying a discount code after checkout.
  • Can you bypass restrictions by tampering with requests?
    Example: Submitting negative quantities or prices in an e-commerce API.

Step 7: Executive Summary Reporting

The first section of the report must contain a summary of the result of the testing done. It must be written in business language with the expectation that it will be read by the members of leadership team.

The succeeding pages will contain technical details that will target the developer team as the audience. Aside from the findings, it must also contain the recommendations on how to improve the security posture of the application tested.

When giving feedback:

  • Be clear and specific about the problem.
  • Suggest secure alternatives or fixes.
  • Prioritize issues:
    • Critical – Must fix immediately (e.g., SQL Injection).
    • High – Fix before merging (e.g., broken access control).
    • Low – Can be scheduled for later (e.g., style issues).

Security Review Checklist

Quick yes/no checklist for reviewers:
[ ] Code changes documented and explained
[ ] Authentication logic verified
[ ] Role-based access control enforced
[ ] All inputs validated and sanitized
[ ] Sensitive data encrypted and protected
[ ] No hardcoded secrets or keys
[ ] Logs do not reveal sensitive data
[ ] Error messages are generic
[ ] Dependencies checked for known vulnerabilities
[ ] Tests include security edge cases

References