Covering your APIs
Web APIs are not exactly a new technology. You can find an API for almost any service offered online. The reason for the popularity is not surprising, APIs easily and efficiently facilitate integration between applications. This inter-application communication allows partnerships to efficiently share data and resources, allowing the automation of many tasks that would otherwise require human interaction.
This inter-application access is a double-edged sword. By design these APIs allow external systems to access, and often manipulate, data and processes within your application. This exposes far more of your internal systems and operations than a webserver ever could. Yet despite this risk it is surprising how many companies fail to adequately protect their APIs.
Web APIs, at their heart, are just web requests.
They are transmitted via the HTTP protocol just like web pages. They are stateless transactions, just like web pages. It shouldn’t be any surprise then that web APIs need all the same protection that your webapplication does.
Use SSL Encryption:
I can’t think of a single web API use case where encryption is a bad idea. If we were talking about the same access to data, or functional ability on a website form you wouldn’t hesitate to secure the webpage with HTTPS; it shouldn’t be any less for APIs that carry that same data / functionality plus any authentication credentials that are submitted along with every request. Just because there is no browser warning to the user is no reason to skip an essential security step.
Validate parameters
Just like above, if this was a web form, you wouldn’t skip this right? Just like a web form data validation protects you from malicious code, errors and just plain nonsensical results. Unlike the web form the direct submitter isn’t a rational thinking person, any gaps or errors in data on their side can cause an automated process to submit all kinds of interesting requests.
Web APIs are so much more than web requests.
APIs also grant an elevated level of access to your internal systems, above and beyond what is available in a typical webpage. Furthermore,most API calls happen within applications internal mechanisms, which aren’t going to read error messages or apply common sense to their inputs. This means, compared to websites, APIs are an increased risk and need to be protected as such.
Use Strong Authentication / Authorization
Unlike web pages, which are generally published for public consumption, APIs are designed to share information with specifically authorized partners.There is an important distinction to be made between Authentication and Authorization. Typically, APIs will use the same token for both and use the term authentication token and authorization token interchangeably. Authentication proves the identity of the requestor, and authorization deals with the permissions of the requestor. OAuth and Authentication Tokens are two common ways to implement strong authentication.Forauthorization implementations consider using access control protocols like XACML to define what a user or role may access.
Restrict Methods
Web requests typically use GET or POST requests to retrieve or send data respectively. HTTP allows for many other lesser known methods like PUT, DELETE, or TRACE. These methods can have unexpected consequences on APIs if they are not properly handled. Restrict request methods to only those explicitly required by the API.
Lastly your APIs are publicly available, and you need to be aware of what information is being leaked through them.
Provide Error Handling Routines
Mistakes happen, sooner or later your application will have to deal with unexpected inputs or events, some of which can cause errors in your application. The default error messages often contain sensitive information about the internal workings of your system.
Warning: mysql_connect() [function.mysql-connect]: Can’t connect to MySQL server on ‘localhost’ (10013) in /var/local/www/include/dbconfig.php on line 23
Failure to handle and censor these errors delivers sensitive information to the end user.
Employ Anti-fusking
Sequential or predictable IDs allow visitors to easily guess IDs of resources they shouldn’t have access to. Hash IDs or UUIDs obscure this information. By itself this might not seem like much of a risk, but combined with any other misconfiguration it makes an attacker’s job an order of magnitude easier.
How DOSarrest can help protect your API:
Use DOSarrest VIP as API gateway
Most secure systems recommend separating your internal / sensitive systems from public systems via an intermediary perimeter system, sometimes known as DMZ. The DMZ, often protected by firewalls, serves as control point restricting what is exposed from the internal zones.
The core design of DOSarrest VIP services function exactly like API gateways, restricting access only to what is explicitly permitted.
Protect APIs with Threat Detection / Removal
Web APIs by and large are far more computationally expensive than websites. Consequently, application DoS attacks are far more effective when targeting APIs.
DOSarrest is able to deal with DoS attacks and other threats like SQL injection at a scale much greater than any appliance could ever manage.
Use Proven Solutions
If its’s not tested, it’s not secure. One of the basic principles of security is to only use proven, tested solutions. At DOSarrest we have been providing internet security solutions for over 10 years. We are not an add-on service to another existing business. We are not generalists. Since our inception DOSarrest was created to stop attacks.
Sean Power
Security Solutions Architect
DOSarrest Internet Security
Source: https://www.dosarrest.com/ddos-blog/securing-your-apis/
Article Link: https://ddosattacks.net/securing-your-apis/