An IP address is basically like the “street address” of a device on a network. Just as your home needs an address so people can find it, every device on the internet or a local network requires an IP address so data can reach it accurately. An IP address serves two main purposes:

• It tells the network who the device is.
• It indicates the device's location, allowing data to locate it.

An IPv4 address consists of 32 bits, divided into four sections called octets. Each octet contains 8 bits, which is why they are called “octets”. 32 bits allow for approximately 4,294,967,296 (2^³²) unique IP addresses.

IPv4 addresses are organized into octets ranging from 0 to 255 and are divided into classes (A through E) for different network sizes:

• Class A: First bit is 0 (0–127) — Large networks with many hosts.
• Class B: First two bits are 10 (128–191) — Medium-sized networks.
• Class C: First three bits are 110 (192–223) — Small networks.
• Class D: First four bits are 1110 (224–239) — Multicast addresses.
• Class E: First four bits are 1111 (240–255) — Reserved for experimental use.

The pool of available IPv4 addresses is running out, as the rapid growth of the number of users has led to more devices like smartphones, laptops, and smart gadgets needing their own IP addresses. The growing risk of IP address exhaustion led to the development of several solutions, including IPv6, which is a 128-bit system. It does help to address the problem of IPv4 exhaustion, which introduces a huge pool of IP addresses, but not so fast, although it does resolve the issue. Many devices and systems were originally designed with the IPv4 protocol in mind and are still in use today. Migrating all those systems to IPv6 is not so easy.

To slow down the exhaustion of IPv4, Network Address Translation (NAT) and Classless Inter-Domain Routing (CIDR) were introduced.

Network Address Translation (NAT)

NAT allows multiple devices on a private network to share a single public IP address, making more efficient use of the IPv4 limited address space. Inside a private network, every device has a private IP which is not accessible from the internet directly. The NAT device (using a router) has at least one public IP. When a device inside wants to send something out to the internet, the NAT device replaces the private source address with its own public IP. NAT also remembers which internal device made the request, so it can send any replies correctly.

NAT Diagram

        [Internet]
            |
        [Public IP: 203.0.113.5]
            |
        +-----------------+
        |      Router     |  <-- NAT device
        |  (performs NAT) |
        +-----------------+
        |       |       |
        |       |       |
[Laptop]  [Smartphone]  [Tablet]
 192.168.1.2 192.168.1.3 192.168.1.4
 (Private IP) (Private IP) (Private IP)

Classless Inter-Domain Routing (CIDR)

While NAT helps multiple devices share a single public IP, another solution called Classless Inter-Domain Routing (CIDR) was introduced to make better use of IPv4 addresses at the network level. Before the CIDR was created, the IPv4 addresses were divided into rigid classes such as A, B, and C.

• Class A (16.7 million addresses)
• Class B (65000 addresses)
• Class C (256 addresses)

The issue with this is that most organizations don’t need such big chunks, which leads to wasted IP addresses. For example, a company with only a few hundred computers might receive a Class B block (65,000 addresses), which leaves tens of thousands of IP addresses unused. This led to a waste of IPv4 space.

CIDR solved this problem by allowing networks to be divided into blocks of different sizes using subnet masks like (/24), instead of being limited to just Class A, B, and C. This is called CIDR notation.

CIDR notation is a way to show an IP address together with its subnet mask in one simple format. Instead of writing the IP and the mask separately, CIDR combines them.
Example:

192.168.1.0/24

Here is the network address, 192.168.1.0, and /24 indicates the subnet mask (the first 24 bits are reserved for the network). This system enables organizations to obtain the exact number of IP addresses they need, and it helps ISPs manage routing more efficiently.

Embedding our web app inside a client’s website using an iframe seemed straightforward at first. Everything worked perfectly except on Safari. Suddenly, users couldn’t log in when our app was loaded inside an iframe. The authentication process was broken, and we knew we had to dig deeper.

In this post, I’ll walk you through what we discovered about Apple’s Intelligent Tracking Prevention (ITP), why it interfered with our session-based authentication, and how we solved the problem so our app works reliably across all browsers including Safari.

What is Intelligent Tracking Prevention (ITP), and Why Does It Matter?

Apple introduced ITP to protect user privacy by blocking third-party tracking cookies. While this is great for users, it creates headaches for developers to resolve the issue in app that rely cookies for authentication — especially when our app is embedded as an iframe on a different domain.

In simple terms: Safari blocks cookies from domains it considers “third-party,” which means our session cookies inside the iframe were being blocked, breaking the login process.

The Root Cause: Third-Party Cookies Blocked in Safari

These were cause of the issue:

• Our client’s website was hosted on client-example.com
• Our application was hosted on our-application.com
• Safari treats our.application.com as a third-party domain inside the iframe on client-example.com
• Because of ITP , Safari blocked the session cookies from our -application.com when loaded inside the iframe on client-example.com.

After some digging , We found that Safari treats subdomins like client-example.com and sub.client-example.com as the same site. Cookies work fine between them because they share registered domain.

What Could we Do? Exploring Our Options

We explosed three possible solutions:

1. Switch to JWT-Based Authentication

Storing JWTs in local storage is possible, so the app wouldn’t rely on cookies and thus avoid ITP blocking. However, implementing this would require rewriting our frontend from server-rendered html.erb views to a Single Page Application (SPA). Given our timeline and resources, this was not feasible right away.

2. Use a Subdomain with a CNAME DNS Record

This was our breakthrough. By hosting our app on a subdomain of the client’s domain (e.g., sub.client-example.com ) via a CNAME record pointing to our servers, Safari considers the iframe first-party. This means cookies are allowed, and session authentication works as expected.

3. Leverage Javascript Storage Access API

Safari provides the Storage Access API, which lets embedded iframes request access to their cookies after user interaction. While useful, it requires users to perform an action (like clicking a button), which can disrupt the login flow and degrade user experience. However starting in 2018 , updates to the API removed the need for user prompts when an iframe request access, making the experience much smoother and less disruptive for users. (more details)

Our Solution: Subdomain Integration via CNAME

We worked with our client to set up a CNAME DNS record so our app was served from a subdomain of their domain. This simple DNS change made Safari treat our iframe as first-party, allowing session cookies to function normally.

On the Rails side, we configured our session store to allow cookies on the client’s domain:

Rails.application.config.session_store :cookie_store,
  key: '_your_app_session',
  same_site: :none,
  secure: true

• Use Secure and SameSite=None for cross-origin cookies
• Avoid SameSite=Lax or Strict, which block cross-site usage

Final Thoughts

ITP is a win for user privacy but a challenge for cross-domain iframe authentication. Understanding how browsers classify domains and cookies is key to finding the right workaround.

If you’re facing similar issues, consider whether a subdomain setup is possible with your client. It’s often the simplest and most effective fix without a major rewrite.