I know being an employee I am paid to do what my boss tells me to do, however:

I am currently writing a website for my company that I work for. We work with sensitive data, so much so that my line manager told me that the overall boss wants me to lock IP addresses to accounts so that you cannot access it unless you are in that particular location.


For my company, we are creating a private portal so the company can log in and get the information about their product from our website. My boss wants it to be that only people logging in from that specific area can access the files. I.E. not going home and logging in and showing their wife of friends, or them getting fired and showing off the documents to our competitors.

The Problem:

Having searched for this it has made me think:

Is locking down an account a really good idea?

I used to play a lot of online games. If your IP address changed, it sometimes caused major problems (i.e. WOW)

What if that company's IP address changes and the entire company is banned from logging in?

I am trying to think of a better solution to this and was wondering if you have any ideas?

  • 1
    This is actually a really good idea. Most companies do not allow employees to access work documents on their home computer. But cloud services tend not to enforce this - you can logon from anywhere. If you get the details right - as Rory explains - this is a good feature for your users.
    – paj28
    Feb 4, 2014 at 13:26
  • Most companies have a small block of static IP. You can log their IP's and do a who is lookup to find the CIDR and/or range. Either than or ask the IT dept for the other companies what ranges they own. Then just assign that range to their account.
    – cybernard
    Feb 2, 2017 at 2:26

7 Answers 7


Locking down access to a site is, in a lot of cases, a good defence-in-depth measure. It shouldn't replace things like user authentication and good password policies but it can be a useful add-on.

In terms of it causing problems, you're right if the companies IP addresses change they it would cause an issue, however most companies will have static IP addresses assigned to them (tends to be a feature of business-grade Internet Access packages)

In terms of stopping that happening, I'd recommend speaking to your network manager and/or ISP to make sure that you're notified ahead of times if they are going to change the IP address. if it's integrated into the change management process, hopefully the chance of disruption would be minimal.

  • Thanks for the reply, I was also worried that IP addresses can be spoofed, so if the person is fired but knows their old IP address then they can still get access
    – Marriott81
    Feb 4, 2014 at 11:00
  • 1
    IP Address spoofing isn't really a practical attack for most people these days over the Internet(it used to be but not with modern systems). Feb 4, 2014 at 11:07
  • Network layer IP spoofing is not effective with TCP (used by HTTPS) connections because the return path is wrong. Application layer IP spoofing is possible if there is an accessible (for the attacker) proxy server running on the company's network.
    – Matrix
    Feb 5, 2014 at 7:51

Aha. I gave an answer on your workplace entry, now here's the implementation side of things.

It's sounding as if your boss wants to make sure your application is only available on the company's intranet (internal network)

This is actually less of a developer concern than it is of an concern for your company's infrastructure team (whoever sets up networking and your web servers)

There are two approaches. If your web server is on the company's intranet, it's nothing more than a matter of explicitly stating in its configuration that only address ranges a.b.c.d - e.f.g.h are permitted. You might share this server with web sites that allow outside visitors, but if you explicity declare this, then it should be enough.

The second approach is a web server that is NOT on the company's intranet. In this scenario, you'll have to restrict the web server's configuration to only allow traffic from your company's external IP address(es). Note that if you are using sharing hosting, this won't always be an available option. If you put your content on a virtual private server (VPS), you can accomplish this by way of a firewall on the machine, the web server configuration, or both. VPS hosting is inexpensive - $5/mo over a digitalocean.com, for example.

This is something that I would avoid doing in code on a user-by-user basis if you can avoid it. The networking approaches will be much easier to maintain because you can probably expect that your networking scenario will change less often that users coming and going.


It is common practice to lock down use for some services to the visitors IP addresses. The way a solution is administering this, is by having a superuser/support user which is allowed to request access to specific IP addresses for the company. This superuser is a employee at a different company. You can then build a routine to grant/decline these requests. I.e. whois information on the ip address, talk to the superuser, etc.

If a user who should have access to the site has the 'wrong' ip address, you can have an information page telling why they are denied access, and that they should contact their superuser to request access to your site.

In the end, you have to trust the superuser that they actually request IP addresses that should be allowed to connect to your site, and not the ip addresses to their friend's wives.


Companies generally have static IP addresses rather than dynamic ones. The main reason for consumers to have dynamic IPs is actually specifically so that they are more protected from attacks based on their IP (and also to prevent them from doing things that the ISP doesn't like, such as running a web server from home.)

As long as the company has a static IP, it is not going to change and using a locked down IP address is not going to be a problem.

The idea of IP lock-down is actually quite commonly used for this type of thing and is ideal as one step in a larger security system. It shouldn't be relied on as the only mechanism, but it is a well established method. Also, even if something did change, unless it is also IP locking updates to the system software itself, you could always change the IP listings that are allowed access under the hood of the site.


It doesn't add any depth of defence if your company has a VPN for travelling sales staff or work-from-home employees.


We had a similar situation with an application I made that deals with protected health information in a hospital environment. Due to HIPAA, the potential consequences of unauthorized access could be very expensive, so these decisions were not taken lightly.

Here is the main security option we offer to restrict access to the site:

  1. Site Admins for each site may add the IP address of the computer they are on to their organization's restricted IP list. This works in most cases as each hospital normally has a single IP, so an admin must be on-site on any computer there to do the configuration. It also guards against accidentally adding the incorrect IP address.
  2. Site Admins for each site may remove any IP address from their organization's restricted IP list. This will let them remove an old IP even if they don't have access to a machine using that IP.
  3. Regular users must log in from an authorized IP for their organization to view PHI.
  4. Regular users may only view PHI from their organization.
  5. Admins may add any IP address or range on a hidden configuration page. This is for internal use only and is only used only in the rare cases where a local admin is not available to do the install or we need to add an IP range for the hospital.
  6. Every IP change is logged. Thus, if an admin added his home computer, viewed some PHI, and then removed his IP address, we can track that.

Interestingly, one issue with this ended up being that some unrelated hospitals had the same IP as other hospitals in the area. This happened because their shared ISP used the same external IP address to route them both. Thankfully, there was no HIPAA breach because of #4.


I would be wary of IP address spoofing since this would allow users to impersonate other IP addresses. Additionally, using an RSA token (or similar device) that is only present at the workplace in a secure area may help to increase security as well.

  • 1
    Spoofing an IP address with TCP is rather difficult, though it is something to be aware of with UDP. This was also mentioned in the comments on Rory McCune's answer. Aug 10, 2018 at 18:47
  • 1
    TCP/IP does not allow spoofing while interacting with a site. The RSA token idea is not very practical, and if the IP could be spoofed, then the token could be stolen.
    – schroeder
    Aug 10, 2018 at 19:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .