Skip to main content
Access rules are only available for Global Nodes.
Access rules provide an additional layer of security for your Chainstack node endpoints by restricting access based on HTTP Origin header values or IP addresses.

​
What are access rules?

Access rules are security filters that control which sources can send requests to your node endpoints. They work by checking incoming requests against your configured rules before processing them. This helps protect your endpoints from unauthorized access and potential abuse. There are two types of access rules you can configure:
  • Allowed origins — Restrict access based on the HTTP Origin header, allowing only requests from specific domains or subdomains.
  • IP addresses — Restrict access to specific IP addresses.

​
How access rules work

When a request is made to your node endpoint, Chainstack checks it against your configured access rules:
  • If you have access rules configured — The request is only processed if it matches at least one of your rules
  • If no access rules are configured — All requests are processed (subject to your normal authentication)
  • If a request doesn’t match any rule — The request is rejected with an error response

​
Adding access rules

You can add access rules from your node details page in the Chainstack console.
1
Navigate to your project.
2
Click on your network.
3
Click on your node name.
4
Click Security.
5
Click the + Add button to create a new access rule.
6
Hover over the created rule, click the edit pencil icon, and click Activate.
You can activate and deactivate the created access rules at any time.

​
Adding an allowed origin rule

Allowed origin rules restrict access based on the HTTP Origin header sent by browsers and applications.
1
In the Add access rule modal, select Allowed origin.
2
Enter the origin URL in the input field (e.g., myapp.com, or myapp.example.com, or *.myapp.com).
3
Click Create to save the rule.
4
Hover over the created rule, click the edit pencil icon, and click Activate.
You can activate and deactivate the created access rules at any time. Supported origin formats:
  • Specific domains: myapp.com, app.example.com
  • Wildcards: *.example.com (matches any subdomain of example.com)
Wildcard rules use the * character to match any subdomain. For example, *.example.com will match app.example.com, api.example.com, and staging.example.com.

​
Adding an IP address rule

IP address rules restrict access to specific IP addresses.
1
In the Add access rule modal, select IP address.
2
Enter the IP address in the input field.
3
Click Create to save the rule.
Supported IP formats:
  • IPv4 addresses: 192.168.1.100
  • IPv6 addresses: 2001:db8::1
Adding multiple origins or IP addresses is not supported at once is not supported. Add them one by one per created rule. CIDR is not supported.

​
Managing access rules

Once you’ve added access rules, you can view and manage them from the Access rules section of your node page.

​
Viewing existing rules

All your configured access rules are listed in the Access rules section on the Security tab.

​
Removing access rules

To remove an access rule:
1
Navigate to your node’s Access rules section.
2
Find the rule you want to remove.
3
Click the delete button (X) next to the rule.
4
Confirm the deletion.

​
Use cases and examples

​
Web application security

Restrict your production node to only accept requests from your application’s domain: 
Allowed origin: myapp.com

​
API server restrictions

If you’re running an API server that connects to your Chainstack node, restrict access to your server’s IP: 
203.0.113.50

​
Server access control

Restrict access to a specific server IP address: 
203.0.113.25

​
Multi-environment setup

For applications with multiple environments, use wildcard rules: 
*.mycompany.com
This allows requests from app.mycompany.com, staging.mycompany.com, dev.mycompany.com, etc.

​
Browser CORS behavior

When using allowed origin rules with web applications, ensure your application correctly sets the Origin header. Modern browsers automatically include this header for cross-origin requests.
For additional security best practices, see How to store your Web3 dApp secrets.