Cloudflare Docs
Learning Paths
Edit this page
Report an issue with this page
Log into the Cloudflare dashboard
Set theme to dark (⇧+D)

Secure your first application

  2 min read

To ensure holistic security precautions, we recommend securing each distinct private application with at least two policies:

  • A Gateway DNS policy with the appropriate identity and device posture values, targeting the domain list that defines your application. Policy enforcement happens at the request resolution event, before the user’s device makes a connection request to the application itself; if denied here, no traffic will reach your private network.

  • A Gateway network policy with the same identity and device posture values as the DNS policy, targeting the IP list that defines your application. You can optionally include the domain list by matching the SNI header. Then, you can include any combinations of ports or protocols that are relevant for application access. Network policy enforcement happens after the user passes the DNS policy, when the user’s device attempts to connect to the target application.

​​ Create a Gateway policy

To create a new policy, open Zero Trust and go to Gateway > Firewall Policies.

​​ Example DNS policy

Traffic SelectorOperatorValue
Domainin listCompany Wiki domains
Identity SelectorOperatorValue
User emailmatches regex.*@example.com
Action
Allow
curl https://api.cloudflare.com/client/v4/accounts/{account_id}/gateway/rules \
--header "X-Auth-Email: <EMAIL>" \
--header "X-Auth-Key: <API_KEY>" \
--header "Content-Type: application/json" \
--data '{
"name": "Company Wiki DNS policy",
"conditions": [
{
"type": "traffic",
"expression": {
"any": {
"in": {
"lhs": {
"splat": "dns.domains"
},
"rhs": "$<DOMAIN_LIST_ID>"
}
}
}
},
{
"type": "identity",
"expression": {
"matches": {
"lhs": "identity.email",
"rhs": ".*@example.com"
}
}
}
],
"action": "allow",
"precedence": 13002,
"enabled": true,
"description": "Allow employees to access company wiki domains.",
"filters": [
"dns"
]
}'

​​ Example network policy

Traffic SelectorOperatorValue
Destination IPin listCompany Wiki IPs
Identity SelectorOperatorValue
User Emailmatches regex.*@example.com
Action
Allow
curl https://api.cloudflare.com/client/v4/accounts/{account_id}/gateway/rules \
--header "X-Auth-Email: <EMAIL>" \
--header "X-Auth-Key: <API_KEY>" \
--header "Content-Type: application/json" \
--data '{
"name": "Company Wiki network policy",
"conditions": [
{
"type": "traffic",
"expression": {
"in": {
"lhs": "net.dst.ip",
"rhs": "$<IP_LIST_ID>"
}
}
},
{
"type": "identity",
"expression": {
"matches": {
"lhs": "identity.email",
"rhs": ".*@example.com"
}
}
}
],
"action": "allow",
"precedence": 13002,
"enabled": true,
"description": "Allow employees to access company wiki IPs.",
"filters": [
"l4"
]
}'

​​ Catch-all policy

We recommend adding a catch-all policy to the bottom of your network policy list. An effective Zero Trust model should prioritize default-deny actions to avoid any overly permissive policy building. For example,

Traffic SelectorOperatorValueLogic
Destination IPin listAll private network rangesOr
SNI Domainin listAll private apex domains
Action
Block
curl https://api.cloudflare.com/client/v4/accounts/{account_id}/gateway/rules \
--header "X-Auth-Email: <EMAIL>" \
--header "X-Auth-Key: <API_KEY>" \
--header 'Content-Type: application/json' \
--data '{
"name": "Catch-all block policy",
"conditions": [
{
"type": "traffic",
"expression": {
"or": [
{
"in": {
"lhs": "net.dst.ip",
"rhs": "$<IP_LIST_ID>"
}
},
{
"any": {
"in": {
"lhs": {
"splat": "net.sni.domains"
},
"rhs": "$<DOMAIN_LIST_ID>"
}
}
}
]
}
}
],
"action": "block",
"precedence": 14002,
"enabled": true,
"description": "Block access to private network.",
"filters": [
"l4"
]
}'

Network policies are evaluated in top-down order, so if a user does not match an explicitly defined policy for an application, they will be blocked. To learn how multiple policies interact, refer to Order of enforcement.