As mentioned in a previous article Front-end, Back-end and database-side – The Structure of an App, server architectures can get pretty complicated. The more sturdy and secure you want your application to be the more complicated it will get. I’ve seen architectures with so many checks and balances that multiple people with multiple types of privileges are necessary to get into the setting of a system and bypass the firewall. Trust me, you can make these things pretty secure. However, many start-ups and small businesses will not need this type of security. Let’s discuss the general security concepts that we will want to consider in these cases.
Let’s start with the client-side, the definition of which has been discussed in Front-end, Back-end and database-side – The Structure of an App. The major security risk that we face on the client-side involves user input. Here, we have to make sure we watch out for malicious code injections from users and bots trying to hack our site. Any developer that has been around for a few years, probably even less, will be aware of these type of security risks and mitigate the risk in their code. However, you will need to make sure that this indeed has been done.
This text as code instructions 'text here meant to be taken as text due to single quotes around it' some other instructions here
//double quote example
This text as code instructions "text here meant to be taken as text due to double quotes around it" some other instructions here
In the above example the ‘input user text here’ is what a user of the app types in as an entry into a textbox. You can see that, if instead they type in ‘input user ‘text here’, the language interpreter can treat the extra ‘ as a marker to end the textual literal and treat the rest of the user input string as code instructions. In this was, a hacker entering input into your app can gain control of your application and even your data.
//quote example with hacker ' injected to end the text string - causing the last part ( text') to be interpreted as code/instructions rather than plain text
code here 'input user' text' code here
//quote example with hacker " injected to end the text string - causing the last part ( text") to be interpreted as code/instructions
code here "input user" text" code here
To prevent this type of hack, your developer can either search for troublesome characters in the input user code and “escape” them, or they can search for all improper characters and if any are found throw a message to the user that the input is unacceptable and the user needs to re-enter the input without funky characters.
//examples of safe code
code here 'input user\' text' code here
code here "input user\" text" code here
//here, single quote is the marker of where to end the text input so a double quote within single quotes is safe
code here 'input user" text' code here
//similar to the above example, a single quote is safe in between double quotes
code here "input user' text" code here
Another way to deal with potentially unsafe user input is to keep a list of all characters that you would not like the user inputting. When a user input comes in make sure that it does not contain any of these characters. If it does, throw a message to the user telling them that the input is not acceptable and they need to try and input it again without any unsafe characters.
This topic in particular can get very extensive, so feel free to ask questions. In general, this type of code injection is referred to as XSS – or Cross-site Scripting.
To continue the discussion of the security of our app architecture let’s proceed to Server-Side Security Concepts in the next article.