I have a project using micro services, front end communicate with back end with multiple Rest API calls.
Both side (Front or Back) have validation. Is there a good way to sync back end and front end validation together.
For example, if there's way to create an validation file (JSON Yaml etc.), which front end and back end could read and understand it perfectly. Only managing validation file, then I can control validation on both end. Instead, to change validation, I need notify both front and back end, it is not efficient.
Please leave your notes if any thoughts across you.
Depending on the specific requirements, something like Protocol Buffers could be used which has many options for validation.
If both endpoints are servers and a browser is not involved, then one option is Consumer Driven Contracts, e.g.: https://spring.io/projects/spring-cloud-contract
If the client is a browser then you could write the validation rules in a programming language that can compile to run both on the server side (e.g. JVM) and in the browser (i.e. JavaScript), such as: https://ktor.io/
Related
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.
I want to implement a tool (a website that can edit a user's own websites) that receives uploads from the browser and stores them in a website specified in the request. However, I want to protect the user from other sites creating requests to my endpoint and doing dirty things with the user's data.
The industry standard for this is to include a randomized token in every rendering of the page, submit it together with the input data, and check the validity of the token on the server side before processing the submitted request.
Is there an automated mechanism for this in the Boomla framework, or is something like this planned?
Implemented, no. Planned, yes.
Currently (v0.9.1), I believe Boomla does check the Referer header, but it stops there. So long, maybe you could implement a cryptographic solution yourself?
How pressing is the issue for you?
Consider that currently, side effects are not possible (eg. send data), thus data leaks are not possible, it won't cause data loss, since we have built in version control. (We are going to expose a casual version control mechanism that works automatically, without commiting, so you'll be backed up even without commiting.) Thus, in effect, your users are safe.
Please disagree if you think otherwise.
As stated. I am using ruby to perform my task. I am to create a webpage that takes in user input and makes calls using the API back and forth. However, I am yet to understand how to deal with these APIs...
When you consume the API you are essentially making use of the service. So you are sending data and are, potentially, getting something back.
When you write a rest client, you are essentially writing an entity which will consume the API. The rest client could also provide some functionality to ease the consumption of the API, for instance if your API requires a time stamp, the rest client could automatically provide the current time stamp, or else provide the user with a nice UI control to do so easily, rather than type something like this: 22-10-2002 12:10:11 GMT.
The client itself can take different forms. It could be a simple page on a web page, or a more complex desktop or mobile application.
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.
We are in the process of designing/creating restful web services that will be consumed client side using XHR calls from various web pages. These web pages will contain components that will be populated by the data retrieved from the web services.
My question is, is it best to design the return data of the web services to match specifically what the client side components will require for each page? Therefore, only one XHR call will be required to retrieve all the data necessary to populate a specific AJAX component or to update a specific page. Or is it more advisable to develop generic web services, that match for instance a database schema, and will require multiple XHR calls client side to retrieve all the data to populate an AJAX component? The second approach seems to lead to some messy coding to chain calls together to retrieved all the data required before updating an AJAX component.
Hopefully this makes sense.
You should always design services based on what they are to provide. Unless you need a service that retrieves rows from the database, don't create one. You may find you need a service that returns complete business entities - they may be in multiple tables.
Or, you may just need a service to provide data for UI controls. In that case, that's what you should do. You may later find that two operations are returning almost the same data, so you may refactor that into one operation that returns the data for both.
My general rule of thumb is to do what ever is the smallest to transmit over the ajax call. In theory, the more data that is sent to the client the slower the update process. This, of course, would necessarily mean specific services for specific pages.