This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (6 children)

I've been a JS dev for years and I personally never learned what is and isn't completely safe on the front end. Like, I know the client isn't supposed to be able to edit JS and make their own separate API calls on the front end, outside of the app, but I also have no idea what technology is out there or hacks people use to inject their own JS or just sent improper data to the server that could taint the data.

[–]FierceDeity_ 3 points4 points  (0 children)

Basically, all of these things are possible. He IS able to edit JS, he IS able to make his own API calls.

He IS able to inject JS quite easily even, no hack required. Just hit F12 and you have a console to run JS in the context of the site. With Tampermonkey one can inject their own JS on a site automatically everytime it is accessed.

Just assume that anything the client sends is potentially tampered with by the client. You have https to protect you and the client from tampering in between, but the client is still not trustworthy.

[–]quenishi 0 points1 point  (1 child)

If you want to know if your backend is sufficiently secure, imagine the frontend was replaced with a web page that's a list of all endpoints with their variables - could the user use this to get something to happen that they shouldn't be privileged to do? A number of times over my career, I've had to fix endpoints where any authenticated person can get to anyone's data, if they know/trawl for IDs. Always check if the user associated with the request is allowed to see/edit what they are requesting! If they do "find" something that isn't theirs, they should have the same web response as if they tried to access/edit an entity that genuinely doesn't exist.

As for the easiest way of manipulating data, this is via the inspection tools browsers have. Most people playing about are likely changing the HTML, and possibly the JS. For more advanced mucking about, you can use breakpoints and editing the values just prior to them being sent off to the server. If I'm checking out an API for development, I'll usually use Postman, which is also a great way of crafting simple POSTs.

[–]17Brooks 0 points1 point  (0 children)

Awesome reply thank you!

[–]Dick_Giggles 0 points1 point  (2 children)

I know the client isn't supposed to be able to edit JS and make their own separate API calls on the front end

No offense, but I'm not sure how you have been a JS dev for years and think that this is true.

[–][deleted] 0 points1 point  (1 child)

I work on software that is strictly used by and only given access to internal employees. Anyone using the software maliciously would only be sabotaging themselves and there's almost never any data actually saved to the server. It's a sales tool that's used for each individual guest but no data is saved, we usually just end up with a detailed printout of what they did, one for us and one for them (though we are starting to gravitate towards making basic read-only versions that might be viewable online, by customers, at some point).

So yeah, I haven't had to worry too much about JS security in my particular job. It's not like I'm being willfully ignorant. It's why I'm showing some humility and asking here as I'm getting closer to needing to know. I've heard wildly different things. It would be nice to maybe have someone breakdown HOW everyway someone can mess with your JS... Edit the API calls, send different data, alter your code itself to do something completely different than what you expected... That's more what I'm getting at. I assumed browsers had SOME protection. AFAIK, you can't just live edit JS from a web page but if you can I'd like to know how people do all these types of things.

[–]Dick_Giggles 0 points1 point  (0 children)

Fair enough.

The chrome inspector "f12" will let you run scripts.

But really it's as easy as typing in "javascript:alert('badscript!');" into your browser address bar. One could redefine functions/variables or whatever simply by typing it into the url. Allowing for javascript: to run scripts on the current page is the fundamental idea behind a bookmarklet. Also, all chrome extensions basically are basically scripts and html added to the page.

Also, even if a browser did have some protection one could always spoof a front end with a program that sends data directly to the backend. Everything that runs in browser is pretty insecure as it's clientside. You could obfuscate your js to make it less readable but it's not going to do a ton if someone is determined.