Now that we understand how the code is supposed to work let’s take a look at what’s actually happening.

Let’s log in and validate that the protected endpoints are protected.

Let’s leverage the user1 account.



Log in with the username,user1, and the password, password1.

You should be redirected to the endpoint /account_secret_phrase?id=1 where you’ll see the string:

“Welcome! Your secret phrase is My S3cret Phrase”.


Click the click here link, and it will redirect you to the following page:


where you will now see the following message:

“Welcome user1! Your secret phrase is My S3cret Phrase”


Let’s see what happens if we change the id value from 1 to 2 in the URL.

What is returned?

Since the application is leveraging the validate_request function correctly, we’ll see the message Access Denied.


Let’s move to the account_password function. Since we’re authenticated as “user1”, let us change our current endpoint in the URL, account_secret_phrase, to the endpoint /account_password?id=1. The new URL should be the following:


When we do this, we should see the following string:

“Welcome user1! Your password hash is 7c6a180b36896a0a8c02787eeafb0e4c”


Let’s try the same thing before, and change the id to 2 in the URL.

Unfortunately, we didn’t receive the “Access Denied” message this time. Rather, we can see the other user’s password hash!

This is an example of an Insecure Direct Object Reference, known as IDOR for short. IDOR vulnerabilities are an incredibly common example of broken access controls. Due to a lack of proper validation, this class of vulnerability allows attackers to directly access potentially sensitive data. Depending on the application, this type of vulnerability can take many forms. An attacker might be able to access sensitive data via a basic number, as we have here, a file name, a GUID value, or some other unique identifier. While some identifiers, such as a GUID, are random enough to be difficult to guess and, therefore, access, some, like basic numbers and filenames, may be easily guessable and accessible.

Now that we understand where the vulnerability exists let’s fix our code in the next exercise.

Take this course for free

Mini Info Outline Icon
By signing up for Codecademy, you agree to Codecademy's Terms of Service & Privacy Policy.

Or sign up using:

Already have an account?