Adwords Firewall
You set up an adwords firewall by opening outbound HTTPS traffic to Google endpoints. You then restrict inbound traffic and scope account roles to specific marketing apps. Many teams start by opening broad network egress so reporting scripts can run. They also share static developer tokens across several internal servers and user machines. When network rules and account roles stay too broad, any machine can change budgets. A single leaked token lets an attacker read customer lists or alter ad sp
Firewall Configuration: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up an adwords firewall by opening outbound HTTPS traffic to Google endpoints. You then restrict inbound traffic and scope account roles to specific marketing apps. Many teams start by opening broad network egress so reporting scripts can run. They also share static developer tokens across several internal servers and user machines. When network rules and account roles stay too broad, any machine can change budgets. A single leaked token lets an attacker read customer lists or alter ad spend.
How an adwords firewall setup works
A proper setup splits network controls from account role controls across your servers. Your network firewall restricts which internal hosts can send outbound requests to Google. Only dedicated worker nodes in your marketing subnet should hold this outbound permission. Because Google uses dynamic IP ranges, network teams filter traffic by domain names. They also require strict TLS checks on every outbound call from those nodes.
On the account side, managers create a dedicated service identity for automated scripts. They assign a standard or read-only role to that identity instead of admin. Each app uses its own OAuth client credentials to request short access tokens. When the worker node runs a job, it passes through the network firewall. It then presents its token to the Google Ads API to read reports. This two-part model keeps random laptops and test servers away from live campaigns.
What native network and role rules miss
Network rules and account roles solve the basic problem of who can connect. The firewall stops unauthorized servers from reaching external ad endpoints on the web. Account roles stop reporting scripts from inviting new users or changing billing details. Together, they form a solid perimeter around your marketing workloads and cloud hosts.
Still, these native controls leave a major gap during active runtime sessions. A network firewall only checks the destination host and port of a packet. Once the connection opens, the firewall cannot read the API commands inside it. Likewise, an account role checks who logs in at the start of sessions. It does not check what individual queries or budget updates do in flight.
If an app holds edit rights, it can pause every campaign at once. It can also pull sensitive customer match lists that contain emails and phone numbers. Native network logs only show that packets moved between your server and Google. They do not record which developer ran a script or what changed. When teams store tokens on local disks for fixing, this risk grows fast. An engineer fixing a bug might run a script against live ad accounts.
Firewall Configuration: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing database and API workflows
Marketing scripts rarely run in isolation from the rest of your backend data. Most ad jobs first query internal SQL databases to build target audience segments. They read order totals, email addresses, and phone numbers from production data tables. Then they send those records out through the firewall to the ad platform.
Securing the outbound network path is only half of the safety puzzle. Teams also need tight controls over how engineers and scripts query internal databases. If a developer queries production tables directly to test an ad sync script, raw customer data lands on their laptop. Masking rules that rewrite emails and phone numbers in query results prevent leaks. Per-command approvals and full audit logs keep both database reads and scripts safe.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Can I use static IP addresses for Google Ads firewall rules?
No, Google rotates the IP addresses used by its advertising and API servers. You should use DNS-based firewall rules or allowlists based on Google ASN blocks.
What port does an adwords firewall rule need to open?
Your firewall must allow outbound TCP traffic on the configured port for HTTPS calls. All modern ad API requests travel over encrypted TLS connections on this port.
How do I stop scripts from pulling raw customer emails for ads?
Hash customer emails and phone numbers inside your database before exporting the records. You can also apply data masking so queries return rewritten values during tests.