I am working on an application right now that needs a way for employees to log in to the back-end of the public facing application for some basic reporting. If you were creating this, would you put the admin interface on the public side or on the intranet side?

Update: It is the back-end of our eCommerce application. I am logging all of the transactions with the CC processor (NOT the sent data, just the response from the processor) and the processed transactions to aide in us being able to troubleshoot when a customer has a problem. Kind of a one-stop-shop instead of looking up in multiple places. They should be in the office when doing this.

This is an ASP.NET MVC project if that matters.

  • This might be more appropriate for the UX.SE site.
    – user25791
    Oct 11, 2011 at 13:20
  • I wasn't sure which site it belonged in. I felt it was more technical side than user side.
    – Mike Wills
    Oct 11, 2011 at 13:33
  • 2
    @MikeWills - If you cannot think of a single reason that it should be on the internet, then make it so you can only access it from the local network, of course you should do EVERYTHING you would do if it was accessible from the internet. Be sure you authenticate and logged all access to this admin website.
    – Ramhound
    Oct 11, 2011 at 15:52

5 Answers 5


It depends on where employees will be logging in from. Do they need to have access to this when they are out of the office? Do you have a company VPN? Do your employees ever work from home? How sensitive is the data?


So it seems basically that your backened will be accessed in your office and contains order information for an eCommerce system. Even though you don't log the information sent to the credit card provider, if you have no reason to access this data outside your company network (i.e. in the office) then I'd put it on the Intranet personally.

You never know if you'll need to log more [sensitive] information in future after client requests or new features you add.

That's not to say that making it internet facing is unsafe though, because you can of course secure it on the internet as well, but the risk is always going to be slightly greater.

  • I updated the question for some more details.
    – Mike Wills
    Oct 11, 2011 at 13:32
  • True, my other concern is those that explore and how to better hide the admin. But moving it internal would fix that.
    – Mike Wills
    Oct 11, 2011 at 13:38
  • 2
    @Mike Wills Security by obscurity isn't obscurity. Who cares who can find the admin tools, as long as they can't authenticate as an admin user and use the tools.
    – Thomas Owens
    Oct 11, 2011 at 15:25
  • @ThomasOwens Good point. It's just come to the fore in the security community. Have you read about this whitepaper refuting Kerckhoffs Principle written by a Royal Holloway University Professor: theregister.co.uk/2011/10/05/security_by_obscurity ?
    – StuperUser
    Oct 11, 2011 at 15:33

I've done this both ways.

For a CMS system, admins could access it from anywhere. This was essential for marketing and sales people who needed to update press releases and so forth on the road, often from mobile devices.

For an ecommerce system, all admin was on the internal office network, only accessible remotely by VPN secured by RSA SecurID. These admin apps were desktop apps (older ones WinForms, newer ones WPF) although they did use some of the same web service based business objects that the consumer ecommerce website used.


@AndyC has some good points about accessibility.

Dig deeper on what the users expect from the site. If they're going to be running reports and wanting to dump things into a spreadsheet, make sure you can get these things to even work on a website and with how much trouble.

For basic viewing and data entry, keep it on the web.

  • This would be basic for payment troubleshooting and then exporting the previous day's transactions in case of problems with the automated system.
    – Mike Wills
    Oct 11, 2011 at 14:11
  • Do you log customer data? Or just information about a particular order (i.e. items bought and their prices).
    – AndrewC
    Oct 11, 2011 at 14:13
  • Customer data is billing contact (address, email, phone). That is all.
    – Mike Wills
    Oct 11, 2011 at 14:32

Assuming you never have bug and never making an error….

Now in the real world,

  • As you don’t need access over the web, don’t provide it, just use a VPN when working from home.

  • Ideally you web facing machines will only have rights to access the stored procedures (or tables) it needs, so limiting the damage if (when) it is broken into.

  • Your internal admin app (internet or even WPF/Winforms) can run on a different machine with a database connections that have more rights.


SSL over HTTP is a given, I shouldn't have to reiterate the importance of that. Furthermore I am assuming you have a strong authentication scheme (mandatory strong passwords, account lockout after so many failed attempts, etc...) Even if the page is hidden, security through obscurity is no security at all.

What you need to concern yourself with is the possibility of whether public facing accounts could have access to information from your payment processor and how that affects PCI compliance. PCI compliance is not just a standard that your payment processor is held to, there are certain security obligations on your end and making such functionality public-facing like you suggest may affect PCI compliance. Many payment processors require their merchants to be PCI compliant anymore and they may charge you additional fees if you are not.

On a side note I would like to add that you may be incompliant with PCI Standards just by logging transaction information with your payment processor.

  • Hmm... we'll have to research what we can and can't store then.
    – Mike Wills
    Oct 11, 2011 at 14:09
  • +1 for mentioning PCI compliance, though this of course depends on the type of data that he is viewing / storing in this backend.
    – AndrewC
    Oct 11, 2011 at 14:09
  • @MikeWills I think as long as you aren't logging ANY information the user passes for a credit card transaction then you are probably fine. You are allowed to store the transaction token however. If you have doubts about this then try just calling your payment processor. They were very helpful in providing internal scanning tools and other assistance to help us meet PCI compliance.
    – maple_shaft
    Oct 11, 2011 at 14:19
  • The only identifying information in that table is the Order Id and Transaction Id. No actual credit card information. We don't even store the last 4 digits of the CC number. We then log the customer name and contact info (address, email, phone) for reporting purposes to bring that information internal for our financial systems. We use First Data. What they return back in their web service is what we store. Saving us from looking up that information in their web portal and on our side to see what went wrong. Hopefully.
    – Mike Wills
    Oct 11, 2011 at 14:30
  • 1
    From day 1 when we started eCommerce, we set the rule. "We do not store credit card numbers."
    – Mike Wills
    Oct 11, 2011 at 16:04

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.