Setting Up CORS Policy for 1C-Bitrix API
CORS (Cross-Origin Resource Sharing) is a browser security mechanism that restricts cross-origin HTTP requests. When building APIs for 1C-Bitrix accessed from different domains or subdomains, proper CORS configuration is essential.
CORS Fundamentals
Browser sends Origin header with every request. Server responds with Access-Control-Allow-Origin header indicating which origins can access the resource. Without proper headers, browser blocks the response.
Implementation in Bitrix
Add CORS headers to API responses:
header("Access-Control-Allow-Origin: https://example.com");
header("Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE");
header("Access-Control-Allow-Headers: Content-Type, Authorization");
header("Access-Control-Allow-Credentials: true");
header("Access-Control-Max-Age: 86400");
For preflight OPTIONS requests, return 200 with CORS headers before processing actual request.
Configuration Strategies
Single Domain: Allow specific domain only.
Wildcard: Allow all origins (not recommended for sensitive APIs):
Access-Control-Allow-Origin: *
Dynamic: Check origin against whitelist at runtime.
Credentials and Security
Set Access-Control-Allow-Credentials: true to allow cookies/auth headers. Avoid using wildcard with credentials—only specific origins allowed.
Common Issues
- Preflight Fails: Missing OPTIONS handler—implement to return CORS headers.
- Credentials Blocked: Credentials require explicit origin (not wildcard).
- Cache Issues: CORS headers cached; clear cache if changing configuration.
Best Practices
- Only allow necessary origins.
- Use specific methods (GET, POST) instead of all methods.
- Limit allowed headers to what's needed.
- Use HTTPS for credential-bearing requests.
- Set appropriate max-age to reduce preflight requests.
Proper CORS configuration balances security and functionality. Too restrictive breaks integrations; too permissive creates security risks.







