I'm developing a web-app which I want to block ip addresses not registered in my database. This web-app should not be accessible for all users, but the users (let's say) I register manually.

The use case is like this:

  • I create username and password for my client.
  • They login(first login for the client)
  • I get the client's machine ip or mac address(somehow)
  • I store this unique address for the client
  • Then all next login attempts should come from the address I store, otherwise I block the attempt.

Thus, it is not possible to login for other guys who know username and password(except my client of course). They also need to access on that machine.

Do you think it makes sense? Do you have other suggestions?

Use Case Example:

Lets say, I'm a wholesaler and I have retail customers. I register one of my new retail customer with username and password and give them the credentials I created. They can easily login, logout...

Assume that the new customer(who I don't truly trust) also deals with my competitor. If he gives the credentials to my competitor, they can see everything, stock status, prices, discounts of product and so on... Because of there are(could be) some customers who I don't trust so much, I have to protect the systems from my competitor.

  • @Laiv: how would a firewall be of any help here? Jul 24, 2017 at 18:15
  • @ArseniMourzenko nevermind! I missed the the point of the use case. My fault!
    – Laiv
    Jul 24, 2017 at 18:24
  • This will be ineffective for lots reasons that have nothing to do with software engineering.
    – Blrfl
    Jul 25, 2017 at 11:02

2 Answers 2


IP-based access controls are not generally sensible because there is no 1:1 relation between IP addresses and users. Multiple users may share the same IP address if they are behind Network Address Translation (NAT), and most users/devices don't have a static IP address. For most internet connections, the IP address is assigned dynamically and the assignment may change infrequently. Additionally, mobile devices (laptops, phones) may frequently move between networks. E.g. a client may use your service from an office on one day, but work from home on another day.

The only scenario where IP-based access controls make sense if all clients have a static IP address for their office. This is part of many but not all business-oriented internet packages. If the client wants to work from another place they would have to configure a VPN so that they can remote into the office network, then access your app from there.

IP-based access controls can be implemented in a number of ways:

  • within the web application, where you check the request metadata. This is the most flexible way and allows you to associate IPs with accounts. Be aware that you want the original request IP. If your app is behind any cache or proxy they should insert the original IP as a header (usually X-Forwarded-For).

  • with a gateway server in front of your web app, e.g. if you run your app behind Apache as a reverse proxy. You will have to update the server configuration for each new client.

  • with firewall rules, with which you can whitelist specific traffic types (e.g. allow TCP traffic to port 80 from customer IP, else drop). However, you'll have to update the firewall config for each new customer since you can't allow access to only your login page and not the rest of the site.

  • by requiring the client to set up a VPN/network bridge from their router to your router. Since all clients connect to the VPN they appear within your network, so your firewall can simply block any incoming traffic that isn't VPN traffic. When properly configured this is a very flexible and very secure mechanism, but requires enterprise-level router equipment and experienced administrators to set up.

So clearly any of these except the first solution (check request metadata within your app) are likely impractical.

While IP-based access controls can contribute to good security under some circumstances, they tend to be inflexible and inconvenient. They will also annoy potential clients who do not have a static IP address. Most likely other mechanisms to fortify your login may be more flexible and add more security, such as encouraging users to pick strong passwords, rate-limiting login attempts (for which per-IP address rate limits may be sensible), password-less authentication via OpenID identity providers, or multi-factor authentication.

  • Thank you for ip-based access explanation. You answered my first question. What about the last one? Do you have anything to suggest in order to achieve the use case?? Jul 24, 2017 at 19:46
  • 2
    @Ademİlhan Your question does not make it clear why authentication by username+password is not sufficient to ensure security. The main risks of passwords are weak passwords and password reuse (which can be reduced by educating users), and online brute force attacks (which can be prevented with simple rate limiting and captchas). If passwords are not sufficient, the normal strategy is to implement multi-factor authentication. Ideally, you can avoid processing any passwords and rely on a third party identity provider, i.e. implement OpenID login.
    – amon
    Jul 24, 2017 at 20:36
  • I have added use case example to be more clear. Jul 25, 2017 at 6:41

Any web framework/language, would it be Flask for Python, Ruby on Rails, ASP.NET MVC or PHP, offer a way to get the client's IP address.

For instance, in PHP, the IP address can be retrieved by using:


Once you get this address, you compare it to the one which is stored in the database for a given user.

Note that this will work only in corporate environments if and only if the IP address is assigned forever to a machine, and only if users don't switch machines. In any other environment, you won't be able to associate an IP address with a particular user, since IP addresses would be assigned dynamically, and occasionally change.

  • Actually my intension was 'how should I do it' more than 'how can I do it' while asking this question. otherwise I would ask on stackoverflow:) Jul 24, 2017 at 19:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.