{"id":2434,"date":"2025-05-14T01:46:24","date_gmt":"2025-05-13T22:46:24","guid":{"rendered":"https:\/\/wafatech.sa\/blog\/linux\/linux-security\/mitigating-cross-origin-resource-sharing-attacks-on-linux-servers\/"},"modified":"2025-05-14T01:46:24","modified_gmt":"2025-05-13T22:46:24","slug":"mitigating-cross-origin-resource-sharing-attacks-on-linux-servers","status":"publish","type":"post","link":"https:\/\/wafatech.sa\/blog\/linux\/linux-security\/mitigating-cross-origin-resource-sharing-attacks-on-linux-servers\/","title":{"rendered":"Mitigating Cross-Origin Resource Sharing Attacks on Linux Servers"},"content":{"rendered":"


\n<\/p>\n

Introduction<\/h2>\n

<\/p>\n

Cross-Origin Resource Sharing (CORS) is a critical security feature for web applications, allowing resources to be requested from a different domain or origin. While this is fundamental for web functionality, improper CORS configurations can lead to severe vulnerabilities, including data theft and unauthorized access. This article dives into how to mitigate CORS-related attacks on Linux servers and implement best practices for securing web applications.<\/p>\n

<\/p>\n

Understanding CORS<\/h2>\n

<\/p>\n

CORS is a mechanism that uses HTTP headers to allow or restrict resources loaded from one domain to be accessed by another domain. For instance, if your web application hosted on example.com<\/code> needs to fetch data from an API on api.example.com<\/code>, CORS headers dictate whether this request will be permitted.<\/p>\n

<\/p>\n

Common CORS Vulnerabilities:<\/h3>\n

<\/p>\n

    <\/p>\n
  1. Overly Permissive Policies<\/strong>: Allowing all origins (Access-Control-Allow-Origin: *<\/code>) can expose your server to attacks.<\/li>\n

    <\/p>\n

  2. Misconfigured Headers<\/strong>: Errors in header settings can lead to security loopholes.<\/li>\n

    \n<\/ol>\n

    <\/p>\n

    Steps to Mitigate CORS Attacks<\/h2>\n

    <\/p>\n

    1. Set Up a Web Server<\/h3>\n

    <\/p>\n

    Ensure you have a Linux server with a web server like Apache or Nginx. Here is a brief setup for both:<\/p>\n

    <\/p>\n

    For Apache<\/strong>:<\/p>\n

    <\/p>\n

    sudo apt install apache2<\/code><\/pre>\n
    <\/p>\n
    For Nginx<\/strong>:<\/p>\n
    <\/p>\n
    sudo apt install nginx<\/code><\/pre>\n
    <\/p>\n
    2. Configure CORS Properly<\/h3>\n
    <\/p>\n
    Apache Configuration<\/h4>\n
    <\/p>\n
    To set CORS for Apache, you can modify the .htaccess<\/code> file or the server configuration file directly. Here\u2019s how you can restrict access:<\/p>\n
    <\/p>\n
    <IfModule mod_headers.c>
    \n    Header set Access-Control-Allow-Origin \"https:\/\/yourtrusteddomain.com\"
    \n    Header set Access-Control-Allow-Methods \"GET, POST, OPTIONS\"
    \n    Header set Access-Control-Allow-Headers \"Content-Type, Authorization\"
    \n<\/IfModule><\/code><\/pre>\n
    <\/p>\n
    Nginx Configuration<\/h4>\n
    <\/p>\n
    For Nginx, you can adjust the server block. It looks like this:<\/p>\n
    <\/p>\n
    server {
    \n    listen 80;
    \n    server_name yourserver.com;
    \n
    \n    location \/ {
    \n        add_header 'Access-Control-Allow-Origin' 'https:\/\/yourtrusteddomain.com';
    \n        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
    \n        add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
    \n
    \n        # Handle pre-flight requests
    \n        if ($request_method = OPTIONS) {
    \n            add_header 'Access-Control-Allow-Origin' 'https:\/\/yourtrusteddomain.com';
    \n            add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
    \n            add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
    \n            return 204;
    \n        }
    \n    }
    \n}<\/code><\/pre>\n
    <\/p>\n
    3. Restrict Methods<\/h3>\n
    <\/p>\n
    Be mindful of what methods you expose via CORS. Only allow those you truly need in your application’s functioning. For example, if your application only requires GET<\/code> and POST<\/code>, avoid allowing PUT<\/code> or DELETE<\/code>.<\/p>\n
    <\/p>\n
    4. Validate Origin Requests<\/h3>\n
    <\/p>\n
    Instead of using the *<\/code> wildcard, use a whitelist of allowed origins. This is often implemented server-side. Here\u2019s a quick example in Python (Flask):<\/p>\n
    <\/p>\n
    from flask import Flask, request
    \n
    \napp = Flask(__name__)
    \nallowed_origins = ['https:\/\/yourtrusteddomain.com']
    \n
    \n@app.before_request
    \ndef limit_access():
    \n    origin = request.headers.get('Origin')
    \n    if origin in allowed_origins:
    \n        response = app.make_response()
    \n        response.headers.add('Access-Control-Allow-Origin', origin)
    \n        return response<\/code><\/pre>\n
    <\/p>\n
    5. Implement Security Headers<\/h3>\n
    <\/p>\n
    In addition to the CORS headers, consider using:<\/p>\n
    <\/p>\n