> For the complete documentation index, see [llms.txt](https://docs.wem.io/platform/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wem.io/platform/wemtipsandtricks/security/blacklist-or-whitelist-ip-addresses.md).
# Blacklist or whitelist IP addresses
## Access Control
By default anyone can access your WEM application. However, this is not always desirable. Some examples:
* you may want to do acceptance testing in the staging area, but limit access only to people within your organization;
* you want to block specific IP addresses from accessing your application;
* your application is only available to certain people or organizations;
* etc.
All of this can be controlled.
To go to the access control functionality, open the project settings page. There you will find `Access control rules`option in the toolbar. When `Access control rules` is selected, you are presented with a list of all defined access control rules that apply to your application. Here you can add/delete/edit access control rules. You can specify individual IP addresses or ranges of IP addresses that you want to whitelist of blacklist (allow access or deny access). And you can even specify whether the rule should apply to e.g. page requests or OData request.\
In other words: you have great control over access to your application.
It is important to understand that **a rule with a higher priority takes precedence over rules with a lower priority**.\
Therefore the order of the rules is crucial: how higher the rules is on the list of rules, the higher the priority.\
By default, everyone has access to the application.
When you create a rule, you have the following options:
* Name: – The name you want to give the rule
* Start IP address – The start of an IP range (inclusive).
* End IP address – The end of an IP range (inclusive).
* Mode – This is either `Allow access` or `Deny access`. This applies to the specified IP range, so here you specify whether the IP addresses are allowed to access the application or not.
* Portal (optional) – By default the rule applies to all portals. However, you can limit this rule to a specific portal.
* Runtime mode – Possible values: `All runtime modes`, `Preview`, `Staging` and `Live`. When specified, this rule only applies to the specified runtime mode.
* Endpoints – Possible values: `All`, `Page requests`, `Webservices`, `Odata`.
Since the default allows access to everyone, adding rules to restrict access for certain IP ranges is basically blacklisting these addresses.
A common scenario would be to grant access to a limited list of known IP-addresses.\
To accomplish this, you need to add rules that specify the IP ranges that should be allowed access.\
Finally, you need to add a rule that denies access to everyone (else).\
But remember: the order of the rules is important!
So to create a plan to have only some ip-addresses or ip-ranges allowed access and all others denied access, make sure that: 1. There is at least one rule that denies access and it is the last rule in the list; 2. All Allow rules should be placed before the Deny all.
**Without a deny-rule, everyone has access.**\
**With a deny-all rule, every rule that comes after this one will have no effect.**
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.wem.io/platform/wemtipsandtricks/security/blacklist-or-whitelist-ip-addresses.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.