The application allows requesting from all domains

The application allows requesting from all domains (Access-Control-Allow-Origin: Null) and that the cross-origin requests can include cookies (Access-Control-Allow-Credentials: true) and so will be processed in-session.

If an attacker can get their domain into the allow-origin header and the allow-credentials header is set to true than the malicious site has essentially the same level of access as the victim user, which could lead to the malicious execution of functions and confidential data theft.

the Access-Control-Allow-Origin’ should never be set to ‘ * ’. If the resource contains sensitive information configure the ‘Access-Control-Allow-Origin’ header to ‘Same-origin’ to allow requests only from the domains that you trust.

No User Input Validation

Unchecked input is the root cause of some of today’s worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation

Never trust user input and always validate them with proper logic

SQL injection is a type of attack that exploits a vulnerability in a web application that uses a database. An attacker can inject malicious SQL commands into the user input, such as a form field or a URL parameter, and execute them on the database server. This can result in data theft, data manipulation, or even complete takeover of the web application.

Suppose a web application has a login form that asks for a username and a password. The web application then constructs a SQL query like this:

SELECT * FROM users WHERE username = '$username' AND password = '$password' where $username and $password are the user input. If an attacker enters the username as admin' -- and leaves the password blank, the SQL query becomes:

SELECT * FROM users WHERE username = 'admin' --' AND password = '' The -- is a comment symbol in SQL, which means everything after it is ignored. Therefore, the query effectively becomes:

SELECT * FROM users WHERE username = 'admin'
This query will return the record of the user with the username admin, regardless of the password. The attacker can then bypass the authentication and log in as the administrator.

Can lead to significant data breaches.

To prevent SQL injection, the web application should use prepared statements with parameterized queries. Prepared statements separate the SQL code from the user input, and bind the input values to the query parameters. This way, the user input is treated as data, not as part of the SQL code. For example, using prepared statements in nodejs, the SQL query would look like this:

db.execute('SELECT * FROM users WHERE email = ?', [email]);

The ? are placeholders for the query parameters, which are set by the setString methods. The user input is never directly inserted into the query, so the attacker cannot inject any SQL commands. This technique can protect the web application from SQL injection attacks.

An insecure API is an application programming interface that does not have adequate security measures to protect the data and functionality it exposes. Insecure APIs can be exploited by attackers to access or manipulate sensitive data, perform unauthorized actions, or disrupt the availability of the API or the web application that uses it.

One example of an insecure API is an API that does not implement proper authentication and authorization mechanisms. This means that anyone can access the API without proving their identity or verifying their permissions. For instance, an API that allows users to view and edit their profile information might not check if the user is logged in or if the user is the owner of the profile. An attacker could then send requests to the API with any user ID and view or modify their profile data

Attackers can gain unauthorized access or manipulate the application's data. Insecure APIs can serve as gateways for a wide range of malicious activities.

To prevent this type of insecure API, the API should use strong authentication and authorization schemes, such as token-based authentication, OAuth, or API keys. These schemes ensure that only authorized users and applications can access the API, and that they can only perform the actions they are allowed to. For example, using token-based authentication, the API would require the user to send a valid token along with their request, which the API would verify before processing the request. The token would also contain information about the user's role and permissions, which the API would use to enforce access control policies. This way, the API would prevent unauthorized or malicious requests.

An attacker obtains access to an object by breaching the security of other objects or data streams.

- API call parameters use the ID of the resource accessed through the API /api/shop1/financial_info.

- Attackers replace the IDs of their resources with a different one which they guessed through

/api/shop2/financial_info. - The API does not check permissions and lets the call through.

- Problem is aggravated if IDs can be enumerated /api/123/financial_info.

Implement authorization checks with user policies and hierarchy.

Do not rely on IDs that the client sends. Use IDs stored in the session object instead.

Check authorization for each client request to access database.

Use random IDs that cannot be guessed (UUIDs).

APIs return more data than needed by the application

One example would be a typical password reset functionality.

When a user requests a password reset for the user account “admin”, the client-side application requests the API for a one-time password. That OTP is sent to the account’s associated mobile number or email id. Additionally, the API also sends back the mobile number, and the client-side application will display a few digits to inform the client to which number the OTP has been sent.

Even if the client-side application filters the response, a motivated attacker can extract the complete mobile number/email address from the raw response leading to data exposure. It is the same case with error messages. An application bug can cause it to send error messages in response, revealing helpful information needed by attackers.

Attacker can gain user's sessitive infomation

Should never rely on client applications for data filtering and always ensure use cases before sending any personally identifiable information (PII) in response.

Many APIs do not check on requests made by a specific user. In this vulnerability, attackers can send multiple requests until the backend is out of resources and cannot serve any other user. These attacks are more commonly called Distributed Denial-of-Service (DDoS) attacks.

Attacker can use botnet - a group of computers which have been infected by malware and have come under the control of a malicious actor - to send requests

Backend server will be overload and can't serve requests any more

Should consistently rate limit requests performed by users and make sure they are not causing unnecessary processing. Can use express-rate-limit for nodejs and middleware throttle in laravel

Insecure session termination is a vulnerability that allows an attacker to hijack or reuse a user's session after they have logged out or become inactive. This can lead to unauthorized access to the user's account or data

Not invalidating the session ID on the server-side after logout or timeout.

Not using HTTPS to protect the session ID from being intercepted or tampered with.

Exposing the session ID in the URL, page content, or other insecure locations.

Not regenerating the session ID after login or logout.

Not setting the "secure" and "httpOnly" flags on the session cookie.

An attacker can capture sessions of the victim and replay them on demand to get authenticated as the victim in the application. Insufficient Session Expiration increases the attack surface that steals or reuses the user's session identifiers.

• Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login

• Invalidate the session ID on the server-side after logout, idle, and absolute timeout

• Exclusively use HTTPS to transfer the session ID and prevent man-in-the-middle attacks

• Never expose the session ID in the URL, page content, or other insecure locations. Use a hidden form field or a cookie instead

• Regenerate the session ID after login and logout to prevent session fixation attacks

• Set the "secure" and "httpOnly" flags on the session cookie to prevent access by client-side scripts or insecure channels

• Set a reasonable session timeout to expire inactive sessions automatically

Error is not well handled and can leak data

- An “HTTP 404 - File not found” error tells an attacker that the requested file doesn’t exist rather than that they don’t have access to the file. This can help the attacker to decide their next step.

- Showing error stacktrace

- Acttacker can mine information from the application container’s built-in error response.

- A stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.

A web application must define a default error page for 404 errors, 500 errors.

This is an attack in which malicious files are uploaded to the server and then executed, to attack the system

- Upload .jsp file into web tree - jsp code executed as the web user

- Upload .gif file to be resized - image library flaw exploited

- Upload huge files - file space denial of service

- Upload file using malicious path or name - overwrite a critical file

Supposed code can be executed in the server context or on the client side

- The file types allowed to be uploaded should be restricted to only those that are necessary for business functionality.

- Never accept a filename and its extension directly without having an allow list filte

Put secret keys and sensitive data directly in code repository

JWT Secret in .env.example

Attacker can use these secrets keys to decrypt data and access to core services

Carefully check the codebase to remove any sensitive data and use Secret Manager to store secret keys

API does not encrypt the data it transmits or receives

anyone who intercepts the network traffic between the API and its clients can read or modify the data in transit. For instance, an API that allows users to make online payments might not use secure protocols like HTTPS or SSL to encrypt the data. An attacker could then eavesdrop on the network and steal the user's credit card information or alter the payment amount.

Attackers can steal or change communication between the two. Hackers could be spying on or eavesdropping on your sensitive data for all you know

To prevent this type of insecure API, the API should use encryption and other security protocols to protect the data in transit and at rest. Encryption ensures that the data is unreadable and unmodifiable by anyone who does not have the key to decrypt it. Security protocols also provide other features, such as authentication, integrity, and non-repudiation, which enhance the security of the data exchange. For example, using HTTPS and SSL, the API would establish a secure connection with the client, verify the identity of both parties, and encrypt the data before sending or receiving it. The API would also use digital signatures to ensure the data has not been tampered with and to prove the origin and destination of the data.

TLS protocol version 1.0 and 1.1 is enabled:

Servers with TLS version 1.0 and 1.1 may be vulnerable to BEAST, POODLE and other cipher suite based attacks. TLS 1.0 and 1.1 have been officially deprecated

TLS 1.0 and 1.1 should be disabled in the configuration for the site and any backend components (i.e. not browsers) previously accessing functionality via TLS should be tested to ensure compatibility with TLS 1.2+.

By carelessness, an application that uses Git for versioning can expose the “.git” directory. More detail: https://medium.com/stolabs/git-exposed-how-to-identify-and-exploit-62df3c165c37

- Can check by go to website domain's /.git

- Install DotGit Extension

The .git directory of source code can contain sensitive information such as API keys, developer comments, AWS keys, and even the password to a system’s administrative screen and logs of all changes made during development

To fix this vulnerability, either remove the git folder from your webserver or ensure that you deny all access to the .git folders.

Apache 2.4:

<DirectoryMatch "" ^/.*/\.git/""> Require all denied </DirectoryMatch>

Nginx:
location ~ /.git/ {
deny all;
}