I've got a public Java web app created with Spring Boot. I'm ready to release it to production and wanted to get some tips on making sure that it is as secure as possible.
It is basically a search engine that uses Apache Lucene in the backed and a lot of javascript in the front end. I am planning on deploying it to Amazon Web Services, while using my local machine as a backup/test enviroment.
Users can search and browse data. The frontend calls REST endpoints using Javascripts XMLHttpRequest to query the backend for content and then displays it to the user.
The app is completely public and there is no user authentication as of yet.
The app also persists user requests to a database for tracking purposes.
Here's what I've done so far to secure it:
Make sure that the REST endpoints fully verify that the parameters given to them in the requests are valid.
What I plan on doing:
Using HTTPS.
Verifying that any put request or url requests have a reasonable size.
What I am considering adding:
Limiting the number of requests a user can make in a given time period. (not sure if Spring-Boot already has a facility to do this, or I should implement this myself)
Use some kind of API key scheme to make sure that my endpoints are only accessed by my front end. (not sure if this is effective and don't yet know how to do this).
Is there anything else that I should consider doing? Do the things I listed above make sense?
Would greatly appreciate any tips on this.
Related
I'm about to launch a SPA app that I built in VueJS but I'm worried about how exposed my API is. Anyone with access to the app could easily just download all of the data I have running through my RESTful API. The API is protected with oAuth, but with signups being free, essentially anyone can literally have all of the data my app provides.
I recently started looking into an SSR framework like Nuxt thinking this would be the solution to my problem. If I make all my RESTful calls server side, I wont have to expose my API to the world and can return HTML partials while still having the niceness of a SPA app. I know even HTML can be scraped, but I'd rather not just hand my whole database to someone in a nice JSON payload.
After playing around with Nuxt, I'm not sure this is what I'm looking for since it only does the initial REST call on the server, and all subsequent ones happen from the client. What are my options when it comes to not exposing my REST API while still having the benefits of a SPA app?
EDIT:
Some backstory if it will help: I have about 30,000 records in a database that are available through a public-facing ASP.NET MVC Core API. I limited the amount of results that can come back with a page request to 60. My VueJS/Nuxt app uses this API to display the data to the user. Since the calls happen from the client-side, my API is open to anyone who wants to hit it. That means some young, enterprising kid could write a small app that loops 500 times and will have the entirety of my database in less than a couple minutes. I know it's impossible to stop scrapers, but I'd like to make this a little harder to accomplish.
I developed a REST API with go (golang), and now I want to design my web frontend. I don't know how can I separate frontend from backend.
I think that I have three choices:
1- Run REST API on one server and the frontend website on another server.
2- Run REST API and frontend website on the same server, but on different ports. For example run REST on port 8080 and frontend website on port 80.
3- Run Both on the same server and the same port, but use different URL paths (or subdomains) for each one.
As I don't know about this stuff, please tell me which one is true or best solution. Or is there any other solution? Does it matter how big my website is?
Either the first or second options will be mostly the same for you to set up and develop with. So you don't lose or gain anything from that perspective, the only deciding factor is your resources and how you expect your backend to be used in the future.
Currently, if you only have one application/frontend calling on the API, having them be on the same server will be the better option since it will have a marginally increased performance compared to the second option.
But, since you chose a RESTful design for your backend, you might want to reuse it for more applications in the future, and if you expect that the increase in calls to the API will start to use up the server resources, then your frontend might suffer from it and then you should consider relocating the backend to a different server.
The whole microservices, RESTful backend design "pattern" was created to decouple the front and back for better scaling, but that might not be necessary for everyone, you have to estimate the amount of use your application will realistically have and think if you might actually reuse the API elsewhere (or if you want to offer the API for others or not).
In the end, if the first and second option present a similar amount of investment for you at the moment, go for the first one, if not, just keep both front and back on the same server and if in the future you realize you need to scale out, you can just relocate the API to a different server/servers.
Is it possible to configure wildfly such that users and agents have "optional" security?
In essence I want form authentication for a web page, silent basic authentication for my services. Most unfortunately, one component of my ecosystem cannot call with basic headers.
That being said I have a work around but it will take some time to implement. For the time being I would desire to basically have optional security. So everything can play nice in the interim.
I know I could change my authentication module to allow everyone through. But with form turned on, requests without a basic header ram back the web page to log in with.
Thanks for any good tips or tricks.
Edit: This would be possible with Spring Security. Using WildFly's inbuilt security mechanisms with undertow seems to limit your flexibility. So much is handled up front before you reach your code, you really are stuck.
However, with spring security, everything is implemented as filters and so you can check the request context for user agents and all kinds of things, and make decisions about each request as you want.
Obviously this wouldn't be a production solution but in development, like was my case, I could have let any request with user agent XYZ run as admin, for the time being.
I have since migrated to Spring Security for our web app security management.
So the short answer is no. The short answer is still no, but the slightly longer answer is to stop using Wildfly's in built security and use Spring Security.
In the long run you could probably create your own undertow servlet extension that would validate authentication or default to admin credentials. This is going to be a lot of work, and spring security has already done a lot of work for you.
We ended up spinning up duplicate of our services without any authentication that our trailing component could call in the meantime. If you don't want to use spring security this is still the best solution I have
I'm working with NodeJS + Mongoose, writing a Single Page Application, so I need to serve some statics and then all the interaction between frontend and backend is done via XHR. Eventually I'm thinking about writing a native mobile app accessing the same backend. Is there any pattern / best practice I should apply here?, I thought that I may need to extract the API to be exposed via Restify, and handle the requests from the webapp only with ExpressJS? or should I just put all the stuff exposed via Restify? I guess my confusion comes from not being worked with Restify before, so any explanation about how is it different from ExpressJS (specially when talking about a Single Page App) is really welcome.
I am implementing a similar solution, mobile app & website with expressjs and backbonejs. I did not use restify because i did not think i needed the extra complexity, there were not that many API endpoints so expressjs handled everything ok for me.
BTW take a look at this post on restify performance, I just saw it today and have not personally validate the contents.
Benchmarking APIs using PerfectAPI vs Express.js vs Restify.js « « PerfectAPI Blog PerfectAPI Blog http://bit.ly/xrTguB
Restify is packaging DTrace and various handlers that Express doesn't. If you just have one API endpoint and don't need DTrace, it doesn't make sense to run Restify.
Also, you might want to try express-resource
I am thinking in using MongoDB as my main database. However, my app is
fully in JavaScript and I wanted to use the REST API, client side.
I still can't understand what security mechanisms can I use in order to
make a JS call to the database without revealing all the data to all the
users.
Please advice on this matter.
Regards,
Donald
First of all, you can enable database auth which will make the REST interface require authentication if connected to from a remote machine.
That said, it's a very bad idea to expose your database like you suggest. Build a persistence abstraction layer in a server technology you're comfortable with (node.js for example) and put all security constraints and authentication there. The advantages are numerous :
You can keep your API stable even if the MongoDB one changes. You can even replace it with another persistence solution if the need arises in most cases.
You can limit the load a single client can put on your database. If you expose the database directly there's very little you can do to avoid people doing expensive queries or even potentially corrupting writes.
You can often do smart app-side caching and optimization that is not possible if every client directly accesses the database (this depends a bit on the app in question though).
Check out Sleepy.Mongoose, it's a REST API interface for MongoDB. I haven't tried it, but it appears to support standard MongoDB authentication.
MongoLab has MongoDB database hosting with a REST API that can be accessed client side, they even through in some jQuery based examples in their support documentation. That said, Remon is right that you sacrifice any security by doing so because you're making your API key public.
RESTHeart is a Web API for MongoDB.
It provides application level authorization and authentication.
Check the security documentation section.
Also some example applications are available on github:
blog example (using AngularJs via $htpp service)
notes example (using AngularJs via Restangular service)