One of my colleagues has a web api call that is checking that the user is logged in and his token matches what is in session (thanks to all of you for your help). Let's say this is layer blue.

After it's confirmed the user is who they say they are, it then makes a call to another API on another server (let's call it layer Red). I'm not sure why he doesn't just call one layer directly but assume there was a good reason for this "Mirroring".

He said he prevents someone from calling layer red directly, and that only layer blue can call it. I asked him how and he said windows basic authentication.

I didn't even look yet at his IIS, etc, but assume there is some basic auth setup.

What are some risks that come to mind in a scenario like this?


3 Answers 3


Basic authentication is not Windows Integrated Authentication. The former uses cleartext usernames and passwords; the latter uses Kerberos (usually) or NTLM tokens. Integrated authentication is secure enough(tm) as long as you set the ACLs properly. It's a common mistake to set the ACLs too permissive (Authenticated Users, say) and rely on the inability of an attacker to get any valid Kerberos tokens because they don't have an account on your domain. Even worse, a programmer might not check for authorization at all, and assume that because the call didn't just fail outright at the IIS level it must be OK.

These things are dumb; make sure you set the ACLs to allow only the users IIS is running as on layer blue access to layer red. As long as you do that, it's secure; or, at least, if someone can break it, you've got bigger problems.


if its meant to be ONLY for users on the windows server, then none, they would have permissions, and breaking out of them requiers an admin password, so if its an internal API/Application that uses windows authentication, the only fear is someone to get a hold of the admin password.

the mirroring thing is something that some poeple call a "second opinion" with verification, and since its the final descision, its smart to only let Red call to Blue, because if you bypass Blue, your only worry would be Red, and since your freind wants 2 verification passes, you have to go through Blue first, and then through Red, to make sure you are the real user!


There are a couple of potential risks here, depending on how exactly this is setup and what the requirements are.

  1. If end users can obtain direct access to layer red and can obtain valid credentials, they then have unfettered access to layer red using only those credentials, skipping the auth check on layer blue completely.

  2. If layer blue only exists as an auth check, it's an additional point of failure, and if it suffers an outage, the system becomes unusable even if layer red is functioning correctly.

  3. If the credentials to access layer red are not unique to the user but to the layer blue application, it will be more difficult to tell if layer red access is actual authorized, as layer red will have a much harder time telling the difference between an authorized access and access by a user with a stolen token for layer blue.

In the end, these risks are probably quite minor. I don't know that the setup in place is necessarily ideal, but it's likely fine, and the risks it mitigates are likely significantly more severe. It's similar in design to many multi-tiered architectures.

You must log in to answer this question.

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