How to hide customerid in a client side application

Question

1.00/5 (3 votes)

See more:

I have an angular single page application which uses an api ,i have to pass customer id as parameter to get client data , but this is not secure since clientid is exposed at front end and any one can easily change the user id and pass in a parameter and he will get other customer data. How can i secure it so that no one can see other client data.

What I have tried:

Researched on it and found few ways but need best practice to do this.

Posted 26-Mar-17 6:57am

Member 9129971

Updated 28-Mar-17 6:59am

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Richard Deeming · Answer 1 · 2017-03-28T06:59:00

Solution 2

What you've described is an Insecure Direct Object Reference:
Top 10 2013-A4-Insecure Direct Object References - OWASP[^]

Using a sequential number to access data for different records makes it trivial for an attacker to guess the URL for other users' data.

You can make their life harder by adding a GUID[^] key to the record, and only using that key to retrieve the data.

But the only real solution is for your code to validate that the user making the request has permission to access the data being requested. How you do that will depend on your database structure and authentication mechanism.

Posted 28-Mar-17 6:59am

Richard Deeming

Comments

Member 9129971 29-Mar-17 16:15pm

I have thought of a guid idea but as you said its not foolproof.And for second point i have two options
first option:use random generated token
on login time user will provide username password, after success provide him token and for next api calls the user will use the token.This token is saved in a database along with a userid, also this token has expiry time.after expiry token will expire and user have to relogin to get new token.
Now we donot need to expose userid and we can just provide data to user against his dynamic expirable token.

second option:use jwt or owin identity token
For this user will provide username password at login time and will get token magically and token generation behind the scene.

what you think is best approach , its not about my database or authenticaiton mechanism its a normal web api security problem.
the first technique is simple so i wish i would go with this since i have very limited time so difficult to learn the other way unless it really needed.
what you will recommend , first option is secure or no?

Richard Deeming 30-Mar-17 8:33am

So long as your API is only accessed over HTTPS, the first option should be OK. It's a similar idea to the "forms authentication cookie" that you'd use on a regular website, except with better control over when it's sent, and thus better protection from XSRF.

But you'll still need to make sure your tokens can't be guessed or intercepted, and that you don't re-use expired tokens.

Member 12392776 · Answer 2 · 2017-03-28T06:17:00

Solution 1

@Html.HiddenFor(model=>model.Id)

Posted 28-Mar-17 6:17am

Member 12392776

Comments

Richard Deeming 28-Mar-17 13:00pm

Firstly, that's not going to prevent anyone from viewing the ID. You can just view the page source, and the value will be there.

Secondly, it's missing the problem. If the record IDs are a sequential number, and there are no access checks on the server, an attacker just needs to keep trying the next number to get other users' data.

Member 9129971 29-Mar-17 16:01pm

for second point:suppose for attacker we have added authentication, and an attacker cannot getinto the system , but anyuser who has provided username password will get authenticated token , and now this user can just guess some other user id and can get his data, since this user is authentic for a system.So the problem is not the unknown attacker the main issue is the authenticated user.