Recently I participated a workshop about building serverless application. And this is my feedback sharing.
What is built in the workshop?
More detail to say, the workshop is actually let developers to have a taste on using a serverless cloud solution to implement a simple web application.
The web application is a kind of simple web page for polling lunch food.
Usual way: Web server with Backend
Usually to build such such web page, we may need a backend web server which serve the web page. And the backend may also need handle user login service, and connect with database for access the polling record data as well.
The “Serverless” way: Delegate backend to “backend-as-a-service” cloud
What means by the “serverless” in the workshop context is “no backend”. It means that developers may no need to handle/worry about the backend part but only focus on building the frontend web page. Hence, in the workshop, I just wrote some static HTML page and static frontend JS script only. (i.e. C Drive上網大法)
But…How can it be “no backend”????
Actually there is still kind of “backend” but it is delegated to the serverless cloud solution (“backend-as-a-service”). Hence, The backend services are hosted on cloud and services exposed as APIs.
And developers(e.g. me) may just writing static frontend page which invoking the cloud APIs in order to use login service and access the polling record data directly.
But My Concerns …
However, after the workshop I have some concerns about such serverless/backend-as-a-service technology.
1) Transparent API key in frontend
In the above simple sample which I played in the workshop, the backend APIs are requiring an static API key to call. But the API key is put in the static frontend page which is transparent to end user. (I can easily see it with firebug)
If the API key is required to call backend service or even accessing cloud database records directly, exposing the API key may introduce security problem if not carefully handled the doors.
My conversation with their engineer
I asked their engineer about my security aspect concerns. And I further ask them if they have aware of it, would it be a factor which pushing such technology to be limited on some private/internal website solutions instead.
The engineer answer me that the webpage in workshop is just for tasting. For other platform like mobile app, the source code is not visible to end user and developers may even use ProGuard to obfuscate the byte code.
Then I didn’t further talk on the questions because I feel they have no way to resolve the security issues.
Andoird app can be cracked to access APK file. And hackers can decompile APK to get source code. While ProGuard may only slow down how hackers do reverse engineering but it cannot prevent them to do so. So the problem is still there.
2) Potential XSS issue
During the workshop I wrote HTML page in local as C-drive-file (i.e. C Drive上網大法), but their “backend-as-a-service” APIs are on their cloud website domain.
Normally such cross domain Ajax call is blocked by browser to prevent webpage running cross site script (i.e. XSS).
Such browser security restriction can be resolve by defining Cross-Origin Resource Sharing (CORS) HTTP headers. And that is what they did.
It is OK if you don’t understand what I said in above paragraph. The fact is that, their cloud service APIs are allowing any website to access them.
What is the potential problem? Of coz … XSS attack.
If an end-user didn’t logout the “serverless” webpage and then continue browsing other websites, there is a chance which other dirty website may try invoking the cloud service APIs to hack something.
What did I learn?
Through the workshop I tasted the serverless/backend-as-a-service technology which is really fancy for developers to build webs without concerning much about the backend part.
However, as I stated, security is a very important concerns. And developers playing such technology must have awareness on the security aspects. Developers should ask themselves about:
Where are the back doors? Is the back doors acceptable? Or shall we use workarounds to cover the back doors? Or is it worth to take the tradeoff to use such technology after our evaluation?
What I have learnt from other BAAS solutions?
From time to time, actually I heard about some other technology concepts which may share some similarity of technology I tried in the workshop.
For example, I have ever heard of some other backend-as-a-service solutions provided by vendors. And they may share some security concerns which I mentioned above.
I have also ever heard of some vendor solution which directly turning the “Database with tables, schema, records” into REST API. And the solution may directly exposing the REST API to external systems. (Database-as-REST-API?)
It may be not that promising as expected although it firstly sounds good because:
1) Simply transforming Database schema into REST API definition may producing some un-developer-friendly naming problems which may not be developer friendly. And the DB schema may not be a developer-friendly representation of data structures for API consumer to understand as it is not intended for such purpose. Actually, usually a common problem is that the DB schema is too complicated and bulky that external domain consumer developers cannot understand how to directly consume it. Exposing database as REST API would not solve such problem.
2) Database has transactions. However, stateless is one of the philosophy of REST API. REST API Resources would usually not providing the same level of transaction controls. So such Database-as-REST-API approach may either broke the Database transaction functionality, or turning the REST API into something violating REST API philosophy.
(Off topic too much….so I would stop here)