When we look at the development world and its evolution in the last few years, we can say that one of the fields that had least followed the ending of barriers discourse was the one focused on API development.
One of the interesting points regarding the APIs is that many developers, for not seeing the APIs as a web application, forget many of the security concepts and best practices built up to this date in the AppSec market. This brings a great risk to the company, since the APIs provide a point of contact between the outside world and the company’s internal applications.
This view is a point that even leads us to think that for having this kind of action, dealing and moving data and transactions, APIs should be perceived with a little more attention, because for its own characteristic, they attract a lot of attention.
If we understand that APIs form a considerable base of application components that allow information to be exchanged between systems, and that initially this model was fundamentally for internal use by companies – that is, without connection to the outside world – we can say that this thought is still dominant. Even though APIs are increasingly taking on a larger and more important proportion, now at the outside of companies, allowing the exchange of information with suppliers, customers and partners.
How professionals see APIs
The SmartBear company did earlier this year, 2020, a survey that was answered by 1500 professionals who work with APIs. Among them: architects, developers and QA professionals. Of this total of participants, 77% answered that they use APIs and understand them as a point of great importance in their structure.
From a usage perspective, APIs are still seen more as a way to maintain and ensure interoperation between the various tools. However, we must not forget that we also have the use to guarantee contact with external partners and suppliers.
Forrest Innovations also points out a detail that we have observed in our projects: many of the API security problems are due to a change in concepts related to the first development models based on SOAP protocol, which are or have been completely migrated to more current models based on REST API.
This is because previously SOAP models were accessed with a little more security, since their connections were guaranteed through the use of VPN. On the other hand, the REST APIs are developed to guarantee access through a browser and / or mobile applications. And they are currently in countless applications that allow, for example, a hotel reservation.
From a development perspective, the best practices – which have been disseminated in the market for a long time – should also apply to APIs. Thus, the treatment of sensitive data on the server side and also the guarantee of minimum privileges must also be used when we talk about development of APIs.
A challenge to be overcome
We must not forget that APIs can also provide access to updates and/or processing that are performed and handled in back-end database. This is because, when mapping their endpoints, many companies fail in this task. After all, we have more and more complex applications in their structure, and poorly mapped or documented.
At this point, we can imagine that ensuring that the access to the API through an authentication process or even the use of a WAF will be one of the points to be strongly evaluated. In the event of an API leak or compromise, all data will be exposed, in times of LGPD this is not good news.
What we have to realize is that there is, indeed, a great challenge to be overcome. After all, the protection of APIs is also impacted by the large amount of technologies, diversity and design that are used in its construction.
In this perspective, we have to clearly define the understanding that an API is, above all, an application – and must be understood as such, following the best practices for its development.
The presence of the Security Champion
We believe that the first issue when it comes to API security is to really understand that, yes, APIs should also receive the same attention that is normally given to other more “traditional” applications.
If we understand this, we will easily realize that we need, as we do with other applications, to build a security thinking around the API, counting on tests and validations throughout the development cycle.
There is also no reason not to treat this specific knowledge as a necessity within the development teams, creating the opportunity to address the issue openly and even conducting training focused on this topic.
One point that we believe would be essential – here not only for API, but for the entire development cycle – is the presence of Security Champion. This profile would allow the creation of a bridge between the development and security teams, and also helping to see these security points inside the process.
As we can see, there is no lack of opportunities and actions that can be taken to improve the security of the APIs. But be sure to tell us: how have you been thinking about this topic?