I have created a backend code in spring-boot for an android app.
My question, is there any rule for distinguishing between the validations at backend side or at frontend side?
For example- for user creation blank fields should be only checked at the frontend side but for testing backend services alone is it okay to have validations on the backend side.
If we just do validations at the frontend side then the problem arises when we test backend services alone.
As general rule, data sent from the client cannot be trusted. E.g. even if the client validated a field is not null, you should assume that field was not validated at all.
You should implement similar validation logic on the backend as well.
Here's the starting point for implementing validation with Spring, based on JSR-303.
It's not only "ok" to have validation on the backend but it's required. As #hovanessyan mentioned, you can never trust the data from the client. Never.
As a rule of thumb, APIs need to be bullet proof. All the edge cases (null-safety, type-safety, min/max, custom validations) should be covered and tested. There's nothing worse than an API responding with a 500.
Lots of devs noticed that there's a bit of validation logic duplication between frontend and backend and this is one of the reasons technologies like Node.js became so popular - you could in theory share the validations.
Also, don't be discouraged by having to duplicate your validation logic. It's tedious but necessary.
Related
I have a website where i have implemented google recaptcha, however it does not have server side validation. I want to know if google mandates server side validation. I have search through web but did not found anything on this.
Any supporting document/link on this is appreciated.
Google does not force to perform the server-side validation but this is a necessary step if you want to ensure you are protected.
If you implement a client-side only validation it means there is still a request to your backend which does not enforce the captcha validation, and potentially can be exploited.
Here is an example where at server-side the validation is executed before the action (post comment, save user details, etc..) is performed.
I need to implement PayPal payment in my Laravel site. I was going for the server side integration, in order to save all the data, transactions and know what they actually bought. But turns out that [the older] server-side integration method [that I was looking at] is archived, and not really the preferred method anymore. Instead, they suggest using the smart buttons, with front end integration only.
Questions:
Is front end only safe? what prevents the user from messing with the JavaScript and editing the sum with whatever they want?
How do I know what they ordered if it is all front end?
What would I have to do if the payed sum does not correspond to the articles in the cart?
What should I be aware of with this system?
Smart Payment Buttons can be used with or without a server-side component.
Here is the front-end pattern that communicates with a server-side integration: https://developer.paypal.com/demo/checkout/#/pattern/server
Notice the fetches to two '/demo/...' placeholder endpoints, which need to be replaced with actual routes of yours. The first should create a v2/order via API and return the orderID. The second should capture that order after the payer approves it via Smart Payment Buttons.
The answers to your questions re: a serverless (client-side only) pattern are:
Nothing
Only what you program the JavaScript to tell you and which it actually successfully tells you, or what you read via email or in your PayPal account or app notifications
Refund the transaction
It's for people who don't want to do the work of implementing server-side routes and API calls.
Developing a SPA in the frontend (with Vue.js) which consumes endpoints from a (Laravel) API in the backend introduces some challenges that need to be tackled:
1. How to sync deployment when introducing new backend/frontend code
If the code is separated in two VCS repositories (frontend/backend) it can be challenging to sync deployment of both frontend and backend making sure that both finish at the exact same time. Otherwise this can lead to unexpected behaviour (e.g. calling endpoints that are not yet deployed or have changed). Anyone came up with a great solution for this? What is your best practice to tackle this problem? What if versioning every little change is not an option?
2. How to make sure that the frontend code of the SPA is being refreshed after deployment?
So you managed to keep your deployments in sync (see problem 1.), but how do you make sure that the SPA code of every currently active end user is being refreshed? With webpack code splitting enabled, the application might break immediately for users that are currently using your app in between a deployment.
How do you make sure that your users are being served the latest JS without having them reload the entire application on every request? What are best practices (besides forcing the user to refresh the entire page via websockets)? Are there solutions that allow currently active users to keep using the application without being forced to refresh while they might just finished something that's ready to be saved?
I am very interested in your findings, learnings and solutions!
1. How to sync deployment when introducing new backend/frontend code
The best practice here is to keep the backend and frontend in the same repo. You can, of course, extract some reusable code out of them to use in other projects but the code base should ideally be in the same repo or you will keep facing these frustrating code sync issues. Even if you look at popular Laravel libraries - they all have the frontend and backend in the same repo.
If that's not option, I would suggest that you use a versioning system that can link the versions of both repos. Yep, that means versioning every little change!
2. How to make sure that the frontend code of the SPA is being refreshed after deployment?
Usually, I'd avoid doing stuff to force a refresh on the client codebase but if you have long user sessions, it may actually make sense.
To do that, you can use any web socket implementation (such as Pusher) and have your CI notify the frontend through web sockets of any deployment. The frontend can then queue a page refresh. Check out this article on how to implement.
The two questions are tightly coupled and can't be answered separately in my opinion. I have some possibile strategies to deal with such a scenario:
1. Never introduce breaking changes in the API
API deployments should be incremental without breaking anything for users using the previous version. In this way you can simply push the changes on your backend and when the backend deployment is completed you deploy the frontend. Easily achieved if you have separate projects.
This can be performed for major releases by prefixing the API with the version:
https://website.url/api/v${version}/${endpoint}
while minor deployments should only be minor adjustments/bugfixes that do not break frontend functionality.
This approach is the best because it ensures absolutely no downtime in the user activity, but requires additional work and may not be feasible in many projects. If the backend does not introduce breaking changes, you can implement a simple polling system (with a long timespan, such as minutes) from the frontend that detects if a reload in necessary to load the new frontend deployment.
2. Standard response for outdated requests
Each request from the frontend includes an information about the version in use by the frontend. It could be a standard header, a param, whatever. You should wrap your requests in a function that add the information before sending the request itself.
If the server detects a request from an outdated frontend, it returns a standard response, such as:
{
"error": "update required"
}
The frontend detects the error and reload the page
I honestly don't like this approach, because the request may be a POST request with some form data and a page reload may lose the user all their input, which is annoying.
1. How to sync deployment when introducing new backend/frontend code
With a staging environment where you run both test suites before pulling on production.
2. How to make sure that the frontend code of the SPA is being refreshed after deployment?
Don't just break your API. Implement a grace period. For example, you could check for updates on every request, then notify the user that a new version is available so that they have to click a button at their earliest convenience. Record the used client version in your DB. Once all your users are updated, you can delete the old endpoints.
So, I'm starting out building a social network web app. I'm looking into how to fit the parts of my stack together and I'm looking for some guidance about what various frameworks will allow me to do. My current stack idea is to have:
Firebase JSON API: serving user, post, comment, and all the other data
EmberFire: to plug that API into EmberJS
EmberJS: my front-end MVC (because I'm new to MVC and Ember seems the most accessible)
What I'm stumbling on at the moment is how I'm going to implement users with this stack. I've looked at basic authentication stuff but I haven't found anything that would allow me to allow certain actions and views for certain users and not others - the basics of a social network really.
Is it sensible to be doing this stuff in front-end MVC? If so what should I be using to do authentication/personalisation? If not, should I just be doing a PHP/SQL setup? I'd rather avoid that because my skills are all front-end.
If you are just getting started, Firebase is a great service to learn on due to their 'back end as a service' model - you will spend more time building/modeling your data and less time running/installing. Not that you won't want to learn more about that later, but it lets you focus on one piece at a time.
From an access perspective, JS/NoSQL vs PHP/MySQL isn't going to be the issue. They each have their own security requirements - it's more that PHP/MySQL has had more time to establish those rules. Additionally, Firebase being a hosted service has it's own set of requirements.
Firebase security rules are a little weird when you first look at them, but they begin to make some sense after you sit with them for a bit. The Firebase docs are actually a pretty great resource. https://www.firebase.com/docs/security/
Basically, if you use a Firebase 'login provider' it makes Firebase act as both a database and a authentication manager, and the combo helps keep users 'fenced' to where you want them. You can use data from other paths, variables, validation rules, etc. You can even make a 'custom login provider' if you need to integrate with an existing one.
Finally, on the client end, your view can respond to whatever Firebase returns - if a user does 'hack' their way through to a page they shouldn't be on client side, no data is returned anyways and no submitted information would be allowed because of the rules.
I don't quite understand why client side validation is a potential security risk or more of a security risk than server side validation? Can someone give me some scenarios?
Ideally you'd do both client and server side and never one or the other. If we take at look at these 3 scenarios, both is the only secure, user-friendly way to do it:
Client Side Only: As mentioned, it doesn't take much to get around these validations if somebody wants to send malformed data to your server (such as SQL injection). NoScript won't run the javascript validation code, and some browsers allow the user to actively change all loaded javascript and html, so a user could unhook the validation javascript from the controls.
Server Side Only: This one is more secure than Client-only by a long shot, but cuts back on user friendliness. They have to send their form to the server, have it validated and receive the error page back saying a particular field was invalid. What's annoying is that if any of those fields were password fields, their values are not repopulated by default. For example, lets say the user didn't input a phone number correctly in an account creation form. When the server spits back the page about how the phone number is wrong, the user will see that, correct the phone number and hit submit again, just to receive another error page about not having entered a password (and entering it again in it's second textbox) even though that wasn't the initial problem.
Client and Server Side: You get the security of the server side validation, something the user will be hard-pressed to interfere with, and the user friendliness of input validation without having to submit the page (whether you validate through purely local javascript or AJAX).
If you absolutely had to pick one, server side would be the way to go. But you shouldn't ever have to pick one or the other.
Using various tools, such as Fiddler, Noscript, Web Developer, etc., I could disable the client-side javascript validation, and modify the data being sent to your server. Depending on the type of data and what the server does with it, one could initiate a SQL injection attack, attempt to compromise the server security, or simply store bogus data.
A lightweight example: Say you have client-side validation to ensure that a zip code is 5 digits or 5+4 digits. If I disable the client-side script, I could leave my 24-digit value in place. If your server doesn't further check the value, and the database is capable of storing all 24 digits, then I have saved the bogus data.
If you do validation only in client-side, someone may disable javascript (or change the js code, with firebug, for example). So, all validations made in js would be useless and user can insert invalid data in your system.
I assume you're talking about a web scenario?
If you're doing client side validation with Javascript, what happens if the user has Javascript disabled? Then they can submit data to the server that has not been validated.
If they were sneaky, they could even post data directly to your server (bypassing your page completely).
If you do server side validation, in addition to or instead of client side validation, then you have an additional opportunity to defend against these scenarios.
Actually, there is a huge security advantage to client-side validation (in combination with server-side validation). If you validate carefully on the client, then ALL the traffic coming into the server should be clean. Except for the attackers. That makes it possible to do much better server-side attack detection. In the big scheme of things, that's probably the most important thing that you could possibly do to protect your applications. See the OWASP ESAPI IntrusionDetector or the OWASP AppSensor for more on this.
Oh, and obviously if the attack starts and finishes in the client, like DOM-based XSS, then you're going to have to validate and encode on the client-side.