Web Server Backend Security (Part 2): Logic Security (CSRF/CORS) and Data Security

Continuing from the first part on encoding security, this article covers the second part of web server backend security: logical security and data security.

1. Logic Security

What is logic security? – CSRF/CORS

CSRF (Cross‑Site Request Forgery) is an attack where the attacker tricks a logged‑in user into sending a forged request, effectively performing a one‑click attack on the target site.

CORS is a browser mechanism that controls cross‑origin resource sharing by adding specific HTTP headers, allowing servers to indicate whether a cross‑origin request is permitted.

2. CSRF Principle

HTTP is stateless, so authentication state (e.g., login cookies) must be sent with each request. Browsers automatically attach cookies for the request’s domain, which attackers can exploit by loading a malicious page that triggers a request to the victim site, automatically including the victim’s authentication cookie.

Thus, if a user C has logged into site A and later visits a malicious site B, the malicious page can send an HTTP request to A, automatically including A’s authentication cookie, allowing the attacker to perform sensitive actions on behalf of C.

3. CSRF Protection Measures

a. Verify HTTP request headers (Referer and Origin) to ensure the request originates from a trusted site. Prefer Origin validation because Referer may be stripped for privacy reasons.

b. Token mechanism: generate a random, secret token stored on the server and sent to the client (e.g., in a hidden form field or cookie). The server validates the token on each state‑changing request.

c. Custom request‑header token: include the token in a custom header (e.g., X‑CSRF‑Token) via XMLHttpRequest, keeping the token out of URLs and Referer logs.

d. Set the SameSite attribute on cookies (Strict/Lax/None) to restrict cross‑site cookie transmission, which directly mitigates CSRF.

4. CORS Risks

a. Header validation alone is insufficient because headers can be forged; unauthenticated cross‑origin requests should never be trusted without additional checks such as session validation.

b. Malicious cross‑origin requests can be used for application‑level DDoS attacks by repeatedly invoking resource‑intensive endpoints.

c. Third‑party services may be compromised, causing them to return malicious data to your site if you blindly trust their responses.

d. Internal information leakage: an internal site that enables CORS can expose internal data to a malicious external site visited by an internal user.

5. CORS Protection Measures

a. Do not trust unauthenticated cross‑origin requests; verify Session ID or authentication cookie.

b. Validate the integrity of received data and expose only the minimal required functionality.

c. Filter illegal requests using multiple criteria (headers, parameters, etc.).

2. Data Security

Data security means protecting data from unauthorized access, use, disclosure, modification, or destruction through a set of technical and procedural measures.

Open‑source components (e.g., fastjson, log4j) may contain vulnerabilities that affect data security.

Key development practices:

Do not expose API documentation (e.g., Swagger UI) to the public internet.

Do not expose debugging interfaces (e.g., Laravel debug, Spring Boot Actuator) externally.

Standardize logging to avoid leaking sensitive information.

General data‑security recommendations:

a. Implement access control through authentication and authorization.

b. Encrypt sensitive data at rest and in transit.

c. Perform regular backups and have a reliable recovery plan.

d. Monitor and audit server and application activity to detect incidents promptly.

e. Keep software and dependencies up to date to patch known vulnerabilities.

3. Summary

Security is paramount; developers act as the first line of defense. By rigorously applying encoding, logical, and data security practices, we can reduce vulnerabilities and protect web services.