I hope my question matches the scope of this site.

I'm developing a CMS. Currently my logged in users are locked to their IP address for the session. Unfortunately a small portion of my userbase constantly jump between two or more IP addresses. Most of them probably use load balancers. Technically it is not necessary to lock the users sessions to one IP address. I did not expect clients to switch between multiple IP addresses for a single page request on my website.

I wonder now, what are the risks in allowing my clients to constantly jump between IP addresses for a page request (for example, CSS files are requested by xxx.xxx.xxx.xxx and JavaScript files are requested by yyy.yyy.yyy.yyy)? Should I generally allow or prohibit that?

a small portion of my userbase constantly jump between two or more IP addresses.

Causes

Assuming that your users aren't actively trying to hide their real IP addresses by using an anonymising service...:

Most corporate examples I have seen are caused by larger companies and some ISP's using a cluster of proxy servers, each with a different external IP-address, with user requests getting load balanced over that cluster.

You may see Dual Stack users making requests over both IPv4 and IPv6 and switching between the two protocols RFC 8305 for subsequent requests.

The other scenario is when I'm at the extreme range of a Wi-Fi access point and my device "randomly" switches between Wi-Fi and cellular data.

Solutions

In the first scenario you might compromise on keeping such IP address "security" in your sessions by only considering the first three octets, as typically such a cluster of proxy servers are all within a small subnet and will have neighboring IP addresses.

In the second and third scenario you will see completely different client IP addresses, from unrelated providers even.

Don't tie you sessions to a specific IP address, that is more likely to break user experience than to provide actual improved security.

I wonder now, what are the risks in allowing my clients to constantly jump between IP addresses for a page request (for example, CSS files are requested by xxx.xxx.xxx.xxx and JavaScript files are requested by yyy.yyy.yyy.yyy)? Should I generally allow or prohibit that?

The primary risk is a malicious user hijacking the session. If you could lock down to one or a small set of IP addresses, you could block users from entirely different IP addresses from hijacking the session.

The problem is that some users do this legitimately. Whether they are using a load balanced proxy or are at the margins of two wireless access points (or whatever), they use multiple IP addresses. So you pretty much have to allow it for those users. And it's hard to tell which users require multiple IP addresses except when they request from multiple IP addresses.

One way to reduce the impact of this is to use HTTPS. Then the malicious actor has to have a way to compromise the secure layer as well as the session cookie. Over an insecure connection, the malicious actor could just use network inspection to compromise a session cookie. But over HTTPS, the same malicious actor needs to have access to one of the ends of the conversation. And if the malicious actor has that, then it's not necessary to use a different IP.

TL;DR: you should generally allow requests from different IP addresses for the same user. There are legitimate reasons this can happen. Use HTTPS instead to protect from that class of exploits.

what are the risks in allowing my clients to constantly jump between IP addresses for a page request

From a security standpoint - zero risks.

Now, from a practical standpoint. It means you cannot use certain types of algorithms for either security or DoS protection.

A simple way to throttle user requests is to track by IP address. Since this doesn't need to interact with your application server you can use services at lower levels to do this. Software like Apache's mod_evasive do this. You can still use these techniques, but user changing IP addresses will reduce their effectiveness. Then again, users will switch IP addresses anyway so these techniques have never really been effective.

A related, but different, use-case is throttling failed login attempts. This is to prevent brute-force password guessing. But again, there is nothing you can do anyway if users change IP addresses. A really serious hacker would not even use his own machines. He'd just buy some time on a botnet (or use his own previously infected botnet) and connect to your service via 10,000 other people's PCs (IP addresses). This is not really related to limiting user's IP address because it is pre-login, but it's something to keep in mind.

There a several reasons why a user may jump to a new IP address.

1. IPv6 privacy extensions, many IPv6 clients nowadays will jump around within the /64 on the lan.


2. Load balanced proxies, the clients request gets routed to one of several proxies each with a seperate IP.


3. NAT pools, the border nat is configured with multiple IP addresses and assigns IP/port combinations from the pool arbitarilly to client TCP connections.


4. The user moves between different networks or parts of a network, common with phones nowadays.


5. Dual stack users may hop between IPv4 and IPv6.

I wonder now, what are the risks in allowing my clients to constantly jump between IPs for a page request

The advantage of locking client sessoins to IPs is it makes session stealing attacks harder. If an attacker has a mechanism that lets them steal the clients cookies but does not let them make connections to your server from the clients IP address then the IP lock will block them from stealing the session.

The downside is as you say it will cause breakage for some users who find their session invalidated for no obvious reason.

Most sites nowadays seem to think the breakage outweighs the benefits of such locking.