Web application security has been, is and will definitely remain a hot topic. If we go into the concept of API (kind of interface that allows data processing), this is even more true: nowadays services and platforms strongly rely on the API model but the security of this interface is often uncertain.
Protektoid and the vision of Web Security
From a Black box security ..
Obviously, we could have keep that as a "secret", even if it is quite easy to discover the API model for someone that is looking for it. So this would have been a small secret that everybody may know ...
Hiding Protektoid application workflow for security reason would have thus meant we relay on the "black box security" concept, which is not the best option, that the least we can say. Besides, as Protektoid is a startup project, there is no reason to already put rules that maywe consider as useless right now and potentially harmful in a near future!
.. to a Full disclosure based security
So instead of hiding our security behind a thin curtain, we decided to make a full disclosure of the API documentation during the "Nuit du hack 2016" security conference. This disclosure will be associated to a bug bounty program that we explain on https://www.protektoid.com/event/ndh-2016.
The objective is simple: by disclosing the documentation and participating to a bug bounty program, we want ethical hackers to review our API and its security model to look for any bugs, even if we are rather confident: we provide security and not opacity!
Protektoid Security implementation
Rely on strong security instead of black boxes, that is great right? But what does this means in term of implementation? Below are some technical information!
Why do we need an API?
Protektoid being a social review platform, the project strongly rely on the API model. For instance, the applications data, scores and other data are processed by our severs so that you can get social recommendations, applications scores and others.
Protektoid API Security
People may simply ask why we do that and more precisely why we are confident about the security model. The reasons are fairly simple are purely technical: we rely on
- open source technologies we are strongly familiar with
- application frameworks and solutions we are strongly familiar with, with for instance MVC implementations to control data visibility
- security frameworks, models and solutions we are strongly familiar with: CSRF protection, input validations
- ... an open API documentation, which is also good for us as we have to review each of our public endpoint to write the documentation about it
But we are never 100% sure, hence the bug bounty!
Protektoid Server Security
Securing the application is good, but what about the server itself? As we
- constraining firewall rules
- immediate connection notification to mitigate any potential attacks as soon as possible
- up-to-date services
- separation of privileges for both application servers and database accesses
- server kernel protections
and even more.
There are quite a good list of interesting documentation about that!
if you are interested about all the security measures we put in place to protect your data and privacy, feel free to get back to us.