I'm creating a quite complex booking form, and some security questions are coming to mind as I work out the design.
The form is for my user's clients to use, so there can't be any login process which they have to go through.
I'm currently contemplating three issues...
Whether to Create an Internal Login Process
Here has been my thought process:
Don't use GET
So none of my server side functions are using GET, as I understand that to be hackable.
Get Data Using Hidden Forms and POST
When I want to get data from the database, I've created a bunch of hidden forms with hidden inputs which I submit via POST to get the data I need. This felt safe to me, until @JonL commented that maybe it is still hackable.
Create a login process
So my app is for people to book onto events, so I have now moved onto creating a login process. When the first database access is made to get the basic details of the event, I've created a login process from some of that data gathered, and now all my POST server actions are protected by that Security Provider too.
Are there other aspects of security here you think I should be considering?
How to Store Price Information
If I read information from the database, it can either be stored on the client side as:
The raw data from the server action
So if the server action is get_prices then we are referencing a price amount as get_prices.data.prices[x].price_amount
In a Session Based Data Store
Which is what I do at the moment, so I can more easily manipulate which prices to display based on the user's input.
Is one of these methods more secure than another in terms of the price value being hacked?
Accumulating The Cart Amount
So I have seen various videos where the ongoing "cart" amount is stored in a Data Store and then at checkout, the cart total in the Data Store is used in the credit card transaction.
Is this quite hackable too?
I am just in the middle of creating an elaborate process where the amount is written to a database table each time a user makes a selection of what to purchase so the final price they will pay is never stored locally.
Is this the recommended way to go, or am I being a bit paranoid? It will certainly be more of a hit on the database...
Hi Antony,
I think you should check how POST and GET methods work. Nothing that really complicated about this and that's how the websites all around the internet work: HTTP Methods GET vs POST
Two basic rules you need to remember:
GET requests should never be used when dealing with sensitive data
Your server actions, which are not used to publicly display data on the page, should be restricted with the Security Restrict step.
Antony, everything on this earth created by a programmer is "hackable", even your highly secured icloud account is hackable
Follow the two rules i mentioned above and you won't have issues...
Your data store data is editable in the browser, as it's stored in the local storage ... you should get the prices and total amounts from the server action on clicking the checkout button.
The info stored in the data store should be only used on the page to show to the user, but not for the checkout.
The first question I would ask is: what are you trying to protect? It is unclear to me.
Accessing information that is publicly available is not hacking. It is just accessing publicly available information. In our context it doesn’t matter if it is through a GET or a POST.
Your confusion comes from thinking that a POST request is some kind of secured channel. They are not channels.
Think of them as types of predefined contracts that set expectations between client and server.
GET: Hey server! Send me this resource I am requesting immediately!
POST: Hey server! Do your thing.
For the GET.
If I am requesting a web page or a txt file with credit card information you need to make sure I am allowed to access it. Because if you don’t put security measures I will get that information just because the GET establishes that you will send me that resource.
For the POST.
You, as server owner, decide what “Your thing” is. But if you decide that your thing is to send me credit card information make sure I am allowed to have it.
Your thoughts are really helping me to understand more of how things work and see what are the issues are as my design evolves from some initial muddled ideas to something more concrete.
So here is what I am trying to protect:
Information I don’t want a hacker to see
I feel clear about this one… just keep it on the server side. So for example, a user specifies who they are through their email address, and is offered the chance to update their mobile phone number… but only the last 3 digits of their existing number is passed through to the client side and they have to enter their existing number before then can make a change.
Information I don’t want a hacker to change
So this is more the price of certain items… and I feel more clear about the way ahead with this now. Bring the prices to the client side for display, but make sure at checkout the prices are taken from the database.
The possibility of some sustained attack on database requests
My sense is that unprotected GET actions allow for this, but a protected GET or a POST action will stop it… but I’m no expert on this!
While most seem keen to manage shopping baskets at client side via data stores/ cookies etc I personally prefer server side database stored baskets as they are much more secure in my opinion. I store baskets against session ids in a database table. It also makes storing then via a save option against a user I'd much easier.
I will store the basket client side to minimise database hits, but at checkout I will go to the database to calculate the final price and use that server side generated value for the payment amount.
If it doesn’t match the client side number… Well they shouldn’t have bothered to hack it!
I guess that’s were we are very different in approach. I find as things scale then browser performance dips before a decent server performance does so i like to offload as much on to the server as possible. I have been caught out so many times when developing an app to find it grinds to a halt on small devices. I can control the processing power of the server, i have no control over low power handhelds
Yes, it is that balance, isn’t it… The user’s compute power is free but uncontrollable, and the server we can control but we have to pay for…
So I’m going for using as much as I can of the user’s first, and if it turns out to be too much for small devices then I’ll switch to bring more of it back to the server.
I guess as we design an app, we just don’t know where these boundaries are until we build it and find out!
Hey Antony, are you going to have like hundreds of thousands of users using high processor power simultaneously?
What kind of are you developing - is it a second amazon/facebook app ?
Well actually Teodor, the basic answer to your question is "yes".
I am developing a product called "Workshop Angel" which has the potential certainly for 10s of thousands of users, and as it is a booking system then each one of those will have many users booking onto their workshops.
Clearly it will take me some years to get to those numbers, but my thinking in each and every moment is one of how my app will scale. So I will use the AWS world to host everything where I know I can most easily scale the resources and manage the app, database and file system servers with fine detail.
My background is as an entrepreneur, so I am certainly developing a product which will be the basis of a significant business.
That is very true Jon... I have one user who is still using my Bubble prototype, and yesterday I showed her how quickly my new booking form loads and she nearly fell off her chair!
