Skip to content

Running in Production

When running Auto-REST in production, it is strongly recommended to deploy the generated server behind a reverse proxy. In additional to their many implicit benefits, modern proxies offer advanced configuration options that Auto-REST alone does not.

The following documentation highlights common proxy features for consideration by administrators. The Nginx proxy is used in examples for demonstrative purposes. Examples are provided for clarification and as a starting point for administrators. They are not intended for use as-is.

Enforcing TLS

Unencrypted connections should be prevented from accessing the API server. Administrators may choose to block these connections outright, or redirect them to a port requiring encryption.

Example: Redirecting to TLS

The following example requires TLS encryption when connecting to the server. It is assumed the API server is running on http://localhost:8081 and SSL certificates are available under /etc/ssl.

server {
    listen 80;
    server_name api.example.com;

    # Redirect HTTP to HTTPS
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name api.example.com;

    # SSL configuration
    ssl_certificate /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/privkey.pem;

    # Proxy configuration
    location / {
        proxy_pass http://localhost:8081;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Enforcing Rate Limits

Rate-limiting provides a safeguard from malicious clients seeking to overwhelm a server with excessive requests. These limits may be applied globally, or on a per-client basis for more refined control.

Example: Nginx Rate Limiting

The configuration below demonstrates rate limiting using the limit_req_zone directive. The api_limit policy enforces a limit of 10 requests per second (10r/s) per user ($binary_remote_addr). The burst parameter allows a temporary burst of up to 20 requests, allowing momentary surges before applying the policy.

server {
    limit_req_zone $binary_remote_addr zone=api_limit rate=10r/s;
    location / {
        limit_req zone=api_limit burst=20;
    }
}

Enforcing CORS Policies

Cross-Origin Resource Sharing (CORS) prevents requests from unauthorized sources against the server. It restricts clients from submitting requests from unrecognized origins, unless explicitly allowed by the target server. This mechanism helps mitigate unauthorized data access from malicious third-party websites.

Example: Nginx CORS Configuration

The configuration below demonstrates a basic CORS policy using the add_header directive. This setup allows requests from any origin (Access-Control-Allow-Origin: '*') and limits the supported HTTP methods.

server {
    location / {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS, HEAD';
        add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type';
    }
}