Disadvantages of Java Script Frameworks

Just a thought which I am sharing…

According to this link Angular JS has two disadvantages. This applies to every JS framework too.

Not Secure − Being JavaScript only framework, application written in AngularJS are not safe. Server side authentication and authorization is must to keep an application secure.

Not degradable − If your application user disables JavaScript then user will just see the basic page and nothing more.

Both the points are serious concerns for me. I think PHP, MySQL, Ajax is a good combo.

My 2 cents. What do you think?

Not just frameworks, but vanilla js too.

Yes, it’s something every dev should know, that anything security related should be handled server-side. Anything client-side is impossibly easy to hack.

It’s the same old thing about “progressive enhancement”. If your page is reliant on js…


Wow… so they are easy to hack.

All the script is there before your eyes to examine, and you can edit it to whatever you like, right there in the browser using dev-tools if you want to.

With server-side a would-be hacker can only guess at what your scripting looks like and any weakness that may or may not exist within it.

Wow… Now I am thinking that this JS and JS framework thingy are all over hyped.

I don’t know much about advanced JS and frameworks and Yes I agree that they may have some +ve features like two way data binding, async networking, speed etc. but security is a very vital thing.

Edit: one option can be to use both… ie. angular, php and mysql together if needed.

They have their (many) uses, but security is not one of them.

hmmm i see. may be in future they will become more secured.

I am seeing these two CRUD applications using these three together and the speed is pretty slow btw.

The point is that client-side is at the client side. That means that the client (or hacker) can see it, read it and edit it at will.
Sure client and server side can be integrated to work together, that can work.
But anything that is client side is “out of your hands” and open to anyone.


Sam, is node js secure or it is also not secure enough?
Edit: never mind, I read this http://www.infoworld.com/article/2607982/node-js/article.html

1 Like

The same thing goes for practically any language that accepts input from the outside world. It’s not the language that makes it insecure per se, it is the poor or maybe naive programming with the language.



True, I’m not saying that server-side is secure overall, it’s only as good as the programmer.
But at least there they can only guess at what vulnerabilities exist in the code and have limited scope for input.
But they do still try, I have detected and recorded many attempts at SQL injection on my sites. Though nothing ever came of it.
Although I was confident they were not likely to be a real threat, I have since bolted up even more doors, enough that they have mostly stopped trying it on me.

is node js secure or it is also not secure enough?

It’s just as secure as Java, C#, PHP, Python, Ruby, or any other language that runs on the server. It’s as secure as the developer making the site.

^ this. Although some server side frameworks are by default more secure than others, but one would hope that a widely used framework will have had the benefit of many eyes and highly experienced developers. A good indication of this is the security record of the framework and how quickly (if at all) they respond to reported security problems.

I will add that on the front-end, javascript may have a role in security regardless that it is fully visible and editable on the client. The generation of and verification of security, however, should be 100% server side in all cases.

For a good article, take a look at this OWASP article on CSRF (cross site request forgery) which is a deep concern of any web site offering the ability to submit forms or make changes based on web requests of any type.


1 Like

So true. How did you detect the SQL injections? Do you automate your query monitoring? Right now i’m relying on Cloudbric to block attacks but if there are vulnerabilities in my code I want to address them

Going a bit off topic here

Originally my pages were set up with the URLs displaying the whole of the filename and full variables, like: example.com/shipping.php?id=52
The first hint was in Analytics, pages visited sometimes show the URLs with a quote mark added on the end.
I then set up my script to detect any unwanted characters in the variables.
In this instance the only thing I expect in the variable is an integer, so it’s easy enough to strip out everything else and make it safe.

$id = preg_replace('#[^0-9]#i', '', $_GET['id']) ;

But what if, in addition to that we check what else may be in that variable?
You can use a second preg_replace or preg_match to check for “unwanted” characters, such as single quotes, double quotes, semi colons and equals, in $_GET['id'] and if any are detected, take appropriate action. Record, report, ban, redirect, whatever you want to do with them.
A common one I found was the addition of 'A=0 on the end or sometimes just a single quote.

But there was no real threat.
For one, as you see the variable to be used is stripped down to just an integer, anything else is removed.
The actual SQL query is a PDO prepared statement with the already sanitised $id bound after preparation.
Also the database user account used by the script to connect to the database is “read only”, it only has privileges to run SELECT queries. So in the unlikely event they did make a successful injection, all they would be able to do is retrieve data that the website is displaying publicly anyway. Why? Because any more sensitive data is stored in a separate, private database which this user account does not haver access to.
Likewise a script that records user input, such as the contact form, to a database which will contain peoples contact details, will be accessed by another user account which has only INSERT privileges, so it can’t possibly retrieve any data.

With this I was catching a whole load of would be hackers, recording and blocking them from the site, to the point it was getting boring.
It turned out with a bit of snooping that the site had been listed on some “SQL Dorks” sites as being “vulnerable”, presumably due to the URL structure /shipping.php?id=50.
The funny thing being that they assume “shipping” to be related to an e-commerce site sending out goods, where as in fact “shipping” refers to pages about historical sea-going vessels.

Anyway, the next step was to alter my URL structure via htaccess so as not to appear vulnerable and seem less appealing to the would be hackers, at the same time making the URLs more user and Google friendly. So now the query strings are less obvious and more readable to humans. So now /shipping.php?id=50 looks like /shipping/50-silvery-wave with the id number still there for the database query with the ships name also for human readability. It would have been nice to just have the ship name for the query, but they are not unique, so I still need a unique id.
The attempted attacks did continue for a while, with the old URLs still being in indexes and redirecting to the new ones, but they gradually died down as they stopped bothering with me. Now I have not seen one of these attempts in several months.


In relation to the original question,
Not Secure - It’s not javascript specifically, it’s all client-side code, the client should NEVER be trusted, everything should always be secured at the server to protect against any malicious requests from the front-end.
It’s like saying C# web api’s aren’t secure because you could put in some code in a input box that would escape a string in order to inject SQL. It’s the developer’s responsibility to take security into consideration.

Not degradable - Html provides tags to provide content to the user where javascript isn’t available, if the entire front end is written in a javascript framework then unless you write a more basic equivelant, you would then just display a message saying this site requires javascript to run.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.