In web application development, the frontend is the part that interacts directly with the user. The backend, on the other hand, is responsible for handling business logic, data storage, and security. In web application architecture, communication between the frontend and backend is done through requests and responses. However, giving full trust to requests from the frontend can have fatal consequences. Here are some of the most dangerous things that can happen if we trust frontend requests too much:
1. Data Manipulation
The frontend is on the client-side, which means that the user has full control over it. With tools like browser developer tools, users can manipulate requests before they are sent to the backend. This includes changing form data, URL parameters, and request headers. Without proper validation and sanitization on the server-side, manipulated data can cause data integrity issues and even trigger security vulnerabilities.
Example:
A user accesses an e-commerce application and sees a form to change their shipping address. Using tools like browser developer tools, the user changes the data that will be sent to the server, for example, changing the user ID to another user's ID.
Danger:
If the backend does not verify that the user ID making the address change request is the same as the user ID that is logged in, this can cause unauthorized address changes, resulting in orders being shipped to the wrong address.
2. SQL Injection
If the backend does not validate and sanitize input from the frontend, this can open the door to SQL injection attacks. Attackers can inject malicious SQL statements into the input that is then executed by the database. This can result in data leaks, data deletion, or even database takeover.
Example:
A login form on a web application submits the username and password to the server. A malicious user enters admin' -- as the username and an empty password.
Danger:
If the backend doesn't use parameterized queries and just inserts input directly into the SQL query, then the query could be:
SELECT * FROM users WHERE username = 'admin' --' AND password = '';
The `--` section comments out the rest of the query, allowing the user to log in as admin without entering a password.
3. Cross-Site Scripting (XSS)
Cross-Site Scripting occurs when an application receives data from a user and displays it on a web page without proper validation or encoding. If the backend receives and processes data from the frontend without adequate checks, attackers can insert malicious scripts that execute in other users' browsers, stealing sensitive information such as cookies or changing the appearance of web pages.
Example:
Users post comments containing malicious scripts:
<script>alert('XSS!');</script>Danger:
If the backend does not sanitize the input and directly stores and displays these comments on the web page, any user who sees these comments will run the script in their browser. This could be used to steal session cookies or perform other malicious actions.
4. Authorization Bypass
Frontends often have UI controls to limit access based on user role. However, these controls are only cosmetic and cannot be used as the only layer of security. If the backend does not verify authorization for each request, users can forge requests to access data or functions that should be restricted.
Example:
The app has UI controls that only show a "Delete User" button for administrators. However, regular users try sending requests directly to endpoints that handle user deletion with tools like Postman.
Danger:
If the backend does not check whether the user sending the request has the administrator role, a normal user could delete another user's account without permission.
5. Parameter Tampering
Parameter Tampering is data manipulation in requests sent from the frontend to the backend. For example, item prices in e-commerce applications or access levels in role-based applications can be changed by the user. Without proper validation and checks, the backend may receive and process this manipulated data, causing financial loss or violation of access rights.
Example:
The e-commerce application sends the product price in the request when adding it to the shopping cart:
{
"productId": 123,
"quantity": 1,
"price": 100.00
}
Users change the price to 1.00 with tools such as browser developer tools.
Danger:
If the backend does not validate the product price based on the data in the database, but instead accepts the price from the request, the user could end up paying a much lower price than they should. But it would be better if the price didn't have to be sent but instead the backend calculated the price independently.
6. Sensitive Data Exposure
Sensitive information such as credit card numbers, personal data, and passwords should never be sent or received in plain text. If the backend trusts the frontend in this regard, sensitive data could be exposed in transit or on the client side, making it vulnerable to eavesdropping or theft.
Example:
Aplikasi mengirimkan nomor kartu kredit dalam request untuk menyelesaikan transaksi:
{
"creditCardNumber": "4111111111111111",
"expiryDate": "12/24",
"cvv": "123"
}
If this data is sent over an insecure connection (HTTP) or stored unencrypted on a server, sensitive data can be stolen by attackers who eavesdrop on the network or access the server.
Kesimpulan
Trusting requests from the frontend without adequate validation and checks on the backend is a very dangerous practice. The backend should always be considered the source of truth and is responsible for verifying, sanitizing, and validating all data received from the frontend. This involves implementing security principles such as input validation, role-based authorization, and data encryption. Thus, we can protect web applications from various security threats and ensure the integrity and confidentiality of user data.
