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';
}
}