API security is the application of any security best practice applied to web APIs, which are prevalent in modern applications. API security includes API access control and privacy, as well as the detection and remediation of attacks on APIs through API reverse engineering and the exploitation of API vulnerabilities as described in OWASP API Security Top 10.

Because APIs (REST, GraphQL, SOAP) are often available over public networks (access from anywhere) and in many cases they are typically well documented, they are highly sensitive to denial of service (DDOS) type incidents. In general, APIs are attractive targets for bad actors. An attack might include bypassing the client-side application in an attempt to disrupt the functioning of an application for other users or to breach private information.

API security is focused on securing this application layer and addressing what can happen if a malicious hacker were to interact with the API directly.

API Security Is A Growing Concern

In a new report released on Monday by ImVision, "API Security is Coming," the company asked over 100 cybersecurity professionals in the US and Europe for insight on the current state of enterprise API security.

Some highlights from the report:

• Over the next 24 months, 91% of security leaders will be making API security a priority, while 80% would like to gain more control over their APIs.
• This is not surprising given how many APIs companies currently have: 73% of enterprises use more than 50 APIs, and growing.
• This is tough to manage, especially when you consider that 4 out of 5 publish APIs for external consumption by partners and clients.
• Ultimately, only 1/3 of security leaders think their APIs get the protection they need.

API development has increased astronomically in the past few years, fueled by digital transformation and the central role APIs play in both mobile apps and IoT. This growth is making API security a top concern, as we clearly also can see from the report.

Understanding API Security Vulnerabilities

A common understanding of the specific threats that enterprises need to defend against is essential. Long known for and relied upon for its original OWASP Top 10 web security vulnerabilities, OWASP recently launched an API-specific list: the OWASP API Security Top 10 vulnerabilities.

OWASP API Security Top 10

• API1: Broken Object Level Authorization
• API2: Broken Authentication
• API3: Excessive Data Exposure
• API4: Lack of Resource & Rate Limiting
• API5: Broken Function Level Auth
• API6: Mass Assignment
• API7: Security Misconfiguration
• API8: Injection
• API9: Improper Asset Management
• API10: Insufficient Logging & Monitoring

Security in API Specifications

Let's consider the #1 in the OWASP Top 10 Web Application Security Risks which is Injection. Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

API specifications like OpenAPI or AsyncAPI support security schemes that can be defined across the APIs, they also support JSON schema for defining the schemas for the parameters, objects that describe the inputs for an API. However, most API specifications are not secure 100% since they are not describing the JSON schema to the full extent possible leaving security holes that can be exploited.

Pet Store API - Example 1

Consider the following parameter called username - taken from Pet Store example):

{
  "name": "username",
  "description": "The name that needs to be fetched. Use user1 for testing. ",
  "schema": {
    "type": "string"
  },
  "in": "path",
  "required": true
}

You have to limit what is accepted as an input, otherwise it could open your backend server to various attacks, like SQL injections or buffer overflows. Try adding a pattern and maxLength to the schema.

Pet Store API - Example 2

Consider the following section in OpenAPI specification - PetStore:

{
  "securitySchemes": {
    "type": "apiKey",
    "name": "api_key",
    "in": "header"
  }
}

We can see that the API is using the api_key header and not the standard Authorization header. This can lead to potential data exposure since the API provides access to dynamic data that are scoped to each API key.

Any caching implementation should have the ability to scope to an API key to prevent cross-pollution. Even if you don’t cache anything in your infrastructure, you could expose your customers to security holes. If a customer with a proxy server was using multiple API keys, such as one for development and one for production, they could see cross-pollinated data.

Here, the recommendation is to ensure Cache-Control headers are properly configured and if possible try to use the common Authorization header since every server knows not to cache based on that header.

app.use((req, res, next) => {  
res.setHeader('Cache-Control', 'no-store, no-cache, must-revalidate');  
res.setHeader('Pragma', 'no-cache');  
// ...
});

Here the example is causing sensitive data exposure which is #3 in the OWASP Top 10 list.

RestCase helps to identify API security flaws during the design phase through automated API schema analysis (register for free here and check-it out for yourself).

Design-first approach security focusing

I already wrote about the importance of API-first or design-first approaches here, but we also must remember that the API security should start with API design. If you wait until you’ve already created your API to think about security, you’re fighting an uphill battle, because you’ll be trying to plug security holes that you could have prevented in the first place.

This was also one of the topics I wrote about that is the future of API security.

Most of the API public documentation is based on API specifications and once are exposed to a client, it is also a potential risk of exposing your API security holes.

Keep in mind, of course, that designing an API that is totally flawless from a security perspective is impossible. You should never assume that your API is so well designed that it has no vulnerabilities. But you can, and should, take steps starting early in the design process to mitigate the risk of security problems within your API.

Summary

Secure API design is the first step toward API security.

API security includes API access control and privacy, as well as the detection and remediation of attacks on APIs through API reverse engineering and the exploitation of API vulnerabilities as described in OWASP API Security Top 10.

Defining the API specification as detailed and secure as possible will increase the confidence of your clients twards your API and will make it much more secure while allowing your developers to learn about the vulnerabilities to watch for before and while implementing the API.

One of the features in RestCase is that it scans your API definitions for both Security and Quality issues and shows insights about them.

We managed to scan about 50 public APIs and aggregated the results in order to write about the top 5 security issues and how to solve them.

1. Not using SSL - Use HTTPS and not HTTP.

The web has moved past standard HTTP. With browser vendors flagging URLs that don't use a secure layer, it's time to do the same for your API.

HTTPS uses Transport Layer Security (TLS) to encrypt traffic. This means communication between the client and server is encrypted.

For your API, this means the content sent from your API is secured from third-parties, but more importantly it means that the access credentials are secured.

2. Authorization in custom header with Caching.

Many of the API are using custom authorization headers but forget to set the caching to false = "Cache-control: no-cache". Web servers knows not to cache the responses when they get an Authorization header, since it may cause a data leak. Consider the following: One is calling a REST API with X-Auth (custom) header for Resource A, and another is doing the same call. The web server may respond with the details of the first call since it is already cached.

This is why it is critical to specify "Cache-control: no-cache" when using custom header for authorization.

HTTP defines a powerful caching mechanism that include ETag, If-Modified-Since header, and 304 Not Modified response code. They allow your clients and servers to negotiate always a fresh copy of the resource and through caching or proxy servers increase you application's scalability and performance.

3. Rate limit

When we think of security, we often think of inappropriate access. It can also be useful to think of API security as managing resources. Rate-limiting is a technique for throttling the usage of an API. It can protect your resources financially, but also ensure that your servers aren't overloaded by a flood of requests at one time.

Many rate-limiting approaches are time-based. They can be set for a billing period to handle overall usage, as well as use a "burst" approach to limit large influxes of requests.

It is advised to add a rate limit to your API for all API calls and in case the limit is reached to return a 429 HTTP status code.

It is advised to add these 3 headers to all the API responses:
1. X-Rate-Limit: 700 (number of allowed requests in the current period)
2. X-Rate-Limit-Remaining: 699 (number of remaining requests in the current period)
3. X-Rate-Limit-Reset: 92 (number of seconds left in the current period until the rate limit resets)

4. Input Validation

API parameters are little holes into your application where malicious users can throw all sorts of rubbish in. They want to compromise your application and all the lovely data held within.

If you’re expecting a date string, make sure it fits the format you’re expecting. If you’re expecting a boolean, reject the request immediately if you get anything except one.

Use enum’s to limit the number of responses an input is allowed to be. If you’re expecting a number, make sure it’s a god-damn number.

The same goes for content-type. Anything that is passed to the API, be it header or body, has to be validated that it’s a permitted value, or a kind of value you’re expecting.

5. Input Sanitization

Ok, so by using input validation we’ve made sure we’re getting the right kind of variables passed in to our API. But we can’t trust this data quite yet.

Sanitise that data! Make sure you’re not allowing anything malicious through. You must filter out anything which you don’t expect, or want in there.

Does your API allow HTML content to be passed through? You’ve got to strip out any javascript you find in there, as that could be part of a Cross Site Scripting (XSS) attack. You should also parse HTML to make sure it won’t break any pages it’s inserted into.

Sanitize any and all text, think usernames, addresses, anything. It could contain javascript, or even worse SQL or operating system commands.

Once that stuff gets into your system you never know it won’t get invoked somewhere. Strip it all out on the way in so that it will not be able to do any harm on the way out.

Summary

Please, use the Authorization header and not a custom header for passing authorization data.

Input validation and sanitization is very important in order to keep your API secured. Specifically, validate everything your application will be handling, before it gets anywhere it could do any damage and sanitize all input before acting on it.

I really recommend to sign-up for RestCase (it is free), upload your OpenAPI specification and see the Quality and Security Insights.

Today, the best practice when implementing APIs on a large scale is to start with an API design stage. This approach is called API design-first, sometimes also known as API-first, schema-first, or design-first.

The design-first approach advocates for designing the API’s contract first before writing any code. This is a relatively new approach, but is quickly catching on, especially with the use of API description formats.

There are several tools that allows you to use the design first approach, one of them is ApiBldr that allows designing the API in a visual and friendly way.

What about Code-first approach?

The code-first approach is a more traditional approach to building APIs, with the development of code happening after the business requirements are laid out, eventually generating the documentation from the code.

Like any product, the concept of the API starts with the business team identifying an opportunity. The opportunity is analyzed and a plan to capitalize on it is created in a text document by strategists, analysts and other business folks. This document is then passed along to the development teams like front-end developers, testers and other R&D team members, which is where the plan is being coded into the API.

Design-first vs Code-first

Design-First: The plan is converted to a human and machine-readable contract, such as an OpenAPI document, from which the code is built as a skeleton and the API definitions are shared accross the R&D teams to begin working in parallel (using mocks).

Code-First: Based on the business plan, API is directly coded. Only at a later stage, an API document can be generated and published. Here the R&D teams are waiting for an initial release of the API to be ready before starting to test it and integrate into client side code.

What is OpenAPI Specification?

OpenAPI is a description of HTTP-based APIs which are typically, RESTful APIs. It comes in the form of a YAML file or definition, that describes the inputs and outputs of an API. It can also include information such as where the API is hosted, what authorization is required to access it, and other details needed for consumers and producers (such as web-developers).

Definitions can be written by hand, by tools, or even generated from code. Once an API has been written down, we say it has been described. Once API has been described into a definition, it becomes a platform for tools and humans to make use of. A typical example of making use of API definitions is to generate human readable documentation from it.

Describing APIs into an OpenAPI definition allows you to leverage tools to help automate a lot of API related processes.

For better understanding and supporting your design-first approach, you can use SaaS products like RestCase, which allows you to build your API definitions using a visual designer, generate great documentation which can be easily changed to your feel & look, API quality and security insights for the design phase and more...

OpenAPI Specification Benefits

OpenAPI is useful for consumers, developers (also called producers) and API designers. Each can benefit from knowing and utilizing tools that consume OpenAPI definitions.

Consumers of the API

If you’re required to consume some API you may need an SDK, and if you have OpenAPI you could generate SDKs for many different languages. The benefit is in having familiarity with a single type of SDK or even customizing the SDK to suit your needs. Each and every API described with OpenAPI can then be turned into an SDK of your choosing.

API Developers (Producers)

Building APIs can be quite fun, particularly when you have a contract to develop against. Building out the boilerplate of an HTTP server is less fun once you’ve done it many times. Generating boilerplate code and stubs from an OpenAPI definition gives you speed and consistency (since you can customize the templates to your needs).

Although there are even more exciting methods of developing APIs, using OpenAPI definitions during runtime to act as a router (have API operations map to classes/methods in code) and as a validation layer (incoming requests will fail validation unless they conform to the OpenAPI definition’s schema). Such practices are becoming more common in microservice-oriented architecture where services are being built-out at a faster rate.

API Designers

Designing APIs has also been given a new focus recently and its importance cannot be understated. APIs should be designed with longevity in mind as changing them, means changing the contract for the consumers and maintaining API versioning. No-one likes getting stuck maintaining an old API!

OpenAPI is a medium to communicate to both consumers and producers, allowing designers to get feedback early in the process and to iterate based on that feedback.

Design becomes even more interesting when it comes to managing more than one API. In those cases, consistency also plays an important role.

Standardizing all your APIs to have consistent patterns becomes possible when you can measure those patterns.

Leveraging OpenAPI for Design-first approach

The OpenAPI definitions, that are described by tools or by extracting annotations from code. They are then transformed into API documentation, server stubs / routers and client SDKs. There are certainly more work flows that could be diagrammed out, ones that provide more specific value depending on the business cases.

Example Workflows:

• Generating API documentation
• Automating parts of testing (APIs)
• Getting early feedback on the design of the API
• Ensuring API consistency especially if you have several API's
• Comparing API changes across versions

Practicing API Design

Today, many companies realized that the API world is basically a universe and changed their way of work accordingly.

Dedicated API architects write a specification and all the stakeholders, from developers to product managers and external consumers, are involved in the process.

APIs became products, so they need to consider not only the technical but also the business and legal concerns. In smaller companies, or when APIs are developed for internal use only, it is the frontend developers who should put on the API designer’s hat. They are the ones who eventually consume the API and therefore should have the best understanding of the requirements.

In any case, the specification should be shared and visible always to the different stakeholders through documentation or the source (json or yaml files).

When the specification is complete, you can then generate mocks and documentation. Thanks to this, frontend and backend development can happen independently, without teams waiting for each other. Backend engineers write the API server to specification and test it, or even leverage tools capable of generating server-side code stubs from OpenAPI to save time writing code. Simultaneously, the frontend developers can build their application and receive correct API responses from the mock server.

Feedbacks

One of the most important aspects of Design-first approach is the ability to get feedbacks very fast through:

Documentation (public, private)

There are many tools that supports automatic documentation for OpenAPI definitions. Sharing this documentation with all possible stakeholders like different R&D team members and perhaps even early API adapters clients can lead to many great inputs and thoughts since each stakeholder has a different view and probably represents different audiences for your API.

Testing

Since the API definitions are a contract, it can be tested even before the implementation of the business logic is done. When the tester is looking at the different models, paths and other aspects of the API, his input can be very valuable, especially at the design phase.

Server \ Client Code

When you generate a server-side code stub based on the OpenAPI definition, the developer or developers who are starting to implement the business logic can find issues at the programming phase and update the API definitions accordingly.

Summary

Design-first approach takes place before or in the early stage of the API development, and the initial output of this approach is a human and a machine-readable definition of the API. You cannot leverage the power of OpenAPI for these stages of the API lifecycle if the specification is an output of your code instead of an input.

You could still argue that you can build a proper API lifecycle without a specification, and you only need OpenAPI to produce documentation. After all, there are enough successful software companies that do not practice test-driven or contract-first development. However, doing so would leave at least half of what OpenAPI can do on the table. It is important to consider that OpenAPI is so much more today — a vast and robust framework for the whole API lifecycle and starting with the design-first approach can boost not only your development time and feedback, but also to create an engagement of your API users and stakeholders.

Here at RestCase we are working with many companies and help them develop secure services and APIs. When working with developers on how to design and build quality APIs and microservices and I am seeing many common design problems that are not organization / company-specific. These problems are better to be addressed at the design phase since it will make your API consistent, more readable and robust.

Here are the top 5 issues I am seeing when it comes to designing an API:

Problem 1: Using body in GET requests

In GET requests, add parameters inside the body, instead of in a URL.
Many servers might not even look at the body of the request when it comes to GET method, since the RFC7231 states that:

A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

You are using HTTP GET method for "writing" while your URIs do not identify a resource but some operation you would like to perform on the resource. HTTP GET has been designed to be idempotent and safe, meaning that no matter how many times you call GET on the same resource, the response should always be the same and no change in application state should occur.

Roy Fielding's comment about including a body with a GET request:

Yes. In other words, any HTTP request message is allowed to contain a message body, and thus must parse messages with that in mind. Server semantics for GET, however, are restricted such that a body, if any, has no semantic meaning to the request. The requirements on parsing are separate from the requirements on method semantics.

So, yes, you can send a body with GET, and no, it is never useful to do so. This is part of the layered design of HTTP/1.1 that will become clear again once the spec is partitioned (work in progress).

Problem 2: Usage of wrong or lengthy names for parameters

Some developers still think that it is better to give a precise parameter name that states the resource, like project_id. When working with REST APIs, try to follow the best practices for URI design.

projectid -> id
projectname -> name
err_msg -> message

Since the URI already should state what is the resource, like project, there is no need for the project_id, but only id.

Also, if you are using lengthy names like "pagenum", first better use a dash(-), instead of an underline("") like "page-num" and secondly, try to avoid it! Just add a description of the parameter in your documentation:

page | defines the page number to search.

Problem 3: Define own error code and error message.

Error Handling

Error handling in many APIs is implemented in the following way: all requests return a response code of 200, even in case of an error. This means that there is no way to distinguish between a successful and unsuccessful response other than parsing the body and checking for the presence of error or error code fields. There is a "problem details response"
which is well-defined by the RFC7807 standard that actually defines the interface of a correct and well-known error response. Unfortunately, it is not used too much since not many developers are aware of it. I wrote about it in [blog post and really recommend everyone to read it.

Error Codes

Please, consider not using this approach of returning a response code 200 (success) when something went wrong unless it is the standard way to go in your API framework. It is a good practice to make use of standard HTTP error codes, which are recognized by most clients and developers.

It makes life easier if the API client could know upfront whether to parse the body or not and how to parse it (as a data object or error object). In cases where errors are application-specific, returning a 400 (Bad request) or 500 (server error) with an appropriate error message in the response body is preferred.

Whichever error handling strategy is chosen for a given API, just make sure it is consistent and according to the widely adopted HTTP standards. This would make our lives easier.

Try to reuse the HTTP protocol first :)

Problem 4: Ignoring caching.

It is easy to ignore the caching by including a header "Cache-control: no-cache" in responses of your API calls. HTTP defines a powerful caching mechanism that includes ETag header, If-Modified-Since header, and 304 Not Modified response code. They allow your clients and servers to negotiate always a fresh copy of the resource and through caching or proxy servers increase your application's scalability and performance.

ETag header

ETag (entity tag) response header provides a mechanism to cache unchanged resources. Its value is an identifier that represents a specific version of the resource.

How it works?

Followings are the generally high-level steps where response header 'ETag' along with conditional request header 'If-None-Match' is used to cache the resource copy in the client browser:

1. The server receives a normal HTTP request for a particular resource, say project with id=123 to get the project details.
2. The server prepares the response but in order to help the browser with caching (By default all browsers always cache the resources (specification) so no special header in the response is needed) and includes the header 'ETag' with its value in the response:
   ETag: "version1"
3. The server sends the response with the above header, the content of project 123 in the body and with the status code 200. The browser renders the resource and at the same time caches the resource copy along with header information.
4. Later the same browser makes another request for the same resource project 123 but with following conditional request header:
   If-None-Match: "version1"
5. On receiving the request for project 123 along with 'If-None-Match' header, the server logic checks whether project 123 needs a new copy of the resource by comparing the current value of the ETag identifier generated on the content of project 123 (or saved in some other place, which is useful when the content is very big in order not to calculate the ETag again) and the one which is received in the request header.
6. If the request's If-None-Match is the same as the currently generated/assigned value of ETag on the server, then status code 304 (Not Modified) with the empty body is sent back and the browser that uses a cached copy of project 123.
7. If the request's If-None-Match value doesn't match the currently generated/assigned value of ETag (say "version2") for project 123 then the server sends back the new content in the body along with status code 200. The 'ETag' header with the new value is also included in the response. The browser uses the new project 123 and updates its cache with the new data.

This is very useful and gives several advantages like saving network bandwidth since this the server does not return content body but relies on the browser for that. This also speeds up the communication between client and server and eventually increases your application security, scalability, and performance.

Problem 5: Returning too much data and long response times.

When you start building your REST API, don't forget that the resources you are returning can increase both in the count and in size. With time, this can cause your microservices to be under increased load and increase the response times of your REST API.
Nobody wants to call an API and get a response after 2 minutes.

Start designing your REST APIs with support for pagination, sorting and filtering.

Filtering

URL parameters are the easiest way to add basic filtering to REST APIs. If you have an /projects endpoint which lists school projects, you can filter via the property name such as GET /projects?state=active or GET /projects?state=active&student=1234. However, this only works for exact matches. What if you want to do a range such as an age or a date range?

The problem is URL parameters only have a key and a value but filters are composed of three components:

The property or field name
The operator such as eq, lte, gte
The filter value

There are various ways to encode three components into URL param key/values.
List all the possible options for filtering in your API documentation and enforce strong validation on the inputs like checking if this is a valid number, valid date and etc...

Pagination

Most endpoints that return a list of entities will need to have some sort of pagination.

Without pagination, a simple search could return millions or even billions of hits causing extraneous network traffic.

Paging requires an implied ordering. By default, this may be the item’s unique identifier but can be other ordered fields such as a created date.

Limit/Page Paging would look like GET /projects?limit=20&page=5. This query would return the 20 rows starting with the 100th row (5 pages of 20 items). Not sending the page, will default it to 0.

Sorting

Like filtering, sorting is an important feature for any API endpoint that returns a lot of data. If you’re returning a list of users, your API users may want to sort by last modified date or by email.

To enable sorting, many APIs add a sort or sort_by URL parameter that can take a field name as the value.

However, good API designs give the flexibility to specify ascending or descending order. Like filters, specifying the order requires encoding three components into a key/value pair.

The current age is the age of science and technology. With the advent of modern technology, the problems associated with modern technology have also increased to a great level.

Application programming interfaces (APIs) have become all the rage nowadays, with enterprise developers now relying heavily on them to support the delivery of new products and services. With the number of APIs increasing, so increasing the data which is passed on the network.

Some of that data is sensitive data like user details, emails, passwords. Consider facebook API which gives you access to many user details including photos, locations and more. This data can be used in many malicious ways, that's why we must focus on security and especially in building secured APs from the start.

API Security Is A Growing Concern

According to the recent researched done by SmartBear (research which was presented in their State of APIs report):

• According to 41.2%, people who gave a response to their research, security was the biggest API technology problems that they wanted to get rid of. They considered it a top priority and wanted foolproof security.
• According to the research, security will be #4 on the area that is expected to provide growth to the API field.
• More than 40% of API providers use some sort of a tool to have a look at the API security, and they want to see if there is a loophole or not.

As the world around us becomes more and more connected via internet connections, the need to build secure networks grows infinitely. APIs continue to be an integral business strategy across industries, whether they are REST, SOAP or ASYNC APIs.

The Internet of Things is another driving force behind the rapid growth in the development of new and smart APIs as these APIs act as an interface between smart devices and the Internet. The latest business trends incorporate the use of APIs, which was not seen before in some of the businesses earlier, such as:

• Banking institutions are incorporating the use of APIs for their clients for better service experience. Banks are adopting an API agile model for efficient and adaptable financial and secure architectures. Healthcare practitioners use various APIs for patients and clients to provide integrated healthcare services and allow interoperability across the organization.
• Retailers are using APIs for smarter e-commerce platforms for their customers, such as mobile payments, etc. Broadly speaking, three main types of APIs are available in practice:

Current State of API Security:

In today's age, a humongous and whopping amount of data is transferred on a daily basis. Some of the data that is transferred using APIs is not that important. On the other hand, some of the data that is shared via API is very confidential, and it must stay safe and encrypted. There are a lot of “Bad people “out there who are always looking for a loophole to jump in and know the secrets of different companies, firms and even reports of national interests. Due to all these reasons, the security of APIs is of a lot of importance, and security must be given the top priority in any scenario.

The modernizing of technology and the problems associated with security are going hand to hand. The stakeholders of the technology world are trying their level best to overcome this mountain like the task, and they want to get rid of security concerns as soon as possible.

Today, the security of APIs are more focused on:

1. Authorization, Authentication, and Auditing (Access Control)
2. Load Balancing and Rate Limiting
3. Communication & Network Privacy (SSL/TLS)

Future of API Security:

In recent times, there are certain trends that API security is going to pass through. From what I can identify here are some of them:

1. DNS Security (DNSSEC)

Encryption goes hand in hand with an API design that grants access to your sensitive information. Since most of this information is transferred over wireless networks, it can be more vulnerable. It’s important to set up SSL or TLS connection to ensure the safety of your data in transit. Using SSL or TLS connection takes your security to another level.

Since standard DNS queries, which are required for almost all web traffic, create opportunities for DNS exploits such as DNS hijacking and man-in-the-middle attacks. These attacks can redirect a website’s inbound traffic to a fake copy of the site, collecting sensitive user information and exposing businesses to major liability.

Like many internet protocols, the DNS system was not designed with security in mind and contains several design limitations. These limitations, combined with advances in technology, have made it easy for attackers to hijack a DNS lookup for malicious purposes, such as sending a user to a fraudulent website that can distribute malware or collect personal information.

Let's take for example DNS hijacking:

In DNS hijacking the attacker redirects queries to a different domain name server. This can be done either with malware or with the unauthorized modification of a DNS server. Meaning that instead of opening www.mybank.com you actually will open www.notmybank.com without even being aware.

The DNS Security Extensions (DNSSEC) is a security protocol created to mitigate this problem. DNSSEC protocol protects against attacks by digitally signing data to help ensure its validity. In order to ensure a secure lookup, the signing must happen at every level in the DNS lookup process.

2. API Design with Security Focus

The key to reaching API developers and users is to formulate a strategic iceberg model that unravels the ease of use and scalability of API design.
When you start to build a microservice that exposes API, start with the API design.

It’s highly recommended to focus on security in the API design process to obtain faster and better results, saving a lot of time and resources. RestCase platform is using AI and sophisticated algorithms in order to validate and inspect the APIs at the design phase and recommend how to handle the security aspects.

3. Artificial Intelligence-Driven API Security

The use of systematic prognostic APIs to integrate huge data, visual, spatial/ location, embedded, web, network, text, and mobile network data has developed to incorporate natural language processing particularly in context per Business Intelligence trends. New sources of real-time data can be useful to detect trends for faster responses to intelligence.

Deep Insight of API Traffic which leads to Trend Analysis, Historical Attack and Anomaly Detection can be used in order to prevent many attacks and do it in a very smart way.

For instance, API specific DoS originates from poorly designed APIs in which rate limiting is not enforced. Sometimes a few API endpoints are computationally heavy to run, such as authentication logic requiring a hashing algorithm. Attackers purposefully exploit and spam such endpoints and take down the entire system.

4. Machine Learning-Driven API Security

AI and ML are excellent tools for the development of such comprehensive and intelligent APIs and can be used to manage challenging and new emerging threat models. These include identifying and flagging anomalous behaviors and malicious data trends and identifying and blocking API attacks and abnormal behavior patterns under multiple environments and circumstances. As a result, continuous learning capabilities are added to the APIs, and anomalous behavior is flagged without prior knowledge of attacks and written policies.

Various machine learning algorithms such as Naive Bayes, K-Nearest Neighbors, Decision Tree, Random Forest, and Support Vector Machine, Deep Learning and Neural Networks are recommended and are being used widely for many API security aspects.

Summary

This era of modern technology is spreading vastly day by day and with the advent of modern technology, the problems have become even more complex, and the stakeholders of this generation are trying their level best to overcome them and facing them gallantly.

We can conveniently conclude that API security is the utmost need of today's cyber world and ML/AI are being used as an effective and smart tool for achieving API security at various layers of the protocol stack. However, more research and development efforts for AI-supported APIs are required, in terms of API business models, analytical and technical blueprints and above all compliance and standardization issues.

I recently had a really interesting interview at the SafetyDetectives blog about cybersecurity and API security state so you are welcome to read it as well.

APIs are channels of communications, through which applications can “talk”. To create a connection between applications, REST APIs use HTTPS. HTTP requests pass through the API channel of communication and carry messages between applications.

Threat actors target REST APIs because they’re after the data stored in HTTP requests. Threat actors also use APIs to initiate attacks such as:

• Man in the Middle (MitM) — manipulates the communication contained within an API message.
• API injections (XSS and SQLi) — inject malicious code (malware or ransomware) into the API codebase or an API message.
• Distributed Denial of Service (DDoS) — repeated calls requesting API connections in fast succession, which is an attempt to overwhelm the server and create an outage. In this article, we’ll provide an overview of API concepts, and provide a table that summarizes the most essential OWASP recommendations for the security of REST APIs.

What is OWASP?

The Open Web Application Security Project (OWASP) is a non-profit organization committed to improving strengthening software security. They achieve this goal by providing unbiased educational resources, for free, on their website.

The OWASP website has a wealth of information, including community forums, documentation, videos, and free tools. Among these resources, you can find the OWASP top 10 vulnerabilities list, which has become a business-standard.

The OWASP top 10 was initially published in 2004 (and updated in 2017), born out of the need to identify the most critical vulnerabilities and prioritize remediation accordingly. While the top 10 list is an essential tool for software security, it’s not enough to keep networks protected.

An unfortunate misconception is that adhering to the OWASP top 10 list is all the security a piece of software requires. In reality, the software of today is built for connectivity and therefore is easily breached, which is why OWASP has created a cheat sheet for REST security.

What Is an Application Programming Interface (API)?

Connectivity between applications is achieved through an Application Programming Interface (API), which is a piece of software that opens and closes channels of communication. The API is composed of protocols, tools, and routines that enable data extraction and distribution.

Internet of Things (IoT) devices use APIs to communicate with each other, the network, the applications they control, and the applications that control them. A smart water heater switch, for example, won’t be able to remotely control the water heater without the use of an API. Web applications use web APIs to communicate with each other, the network, and IoT devices.

Connecting a social media account, for example, to a game application, requires the use of an API, another example are chrome extensions that in order to work with the browser, need to connect to the browsers API.

What is a REST API?

Representational State Transfer (REST) is an API implementation approach that uses the Hypertext Transfer Protocol (HTTP) to create connections. The REST API uses HTTP to gather data, transfer data and coordinates the execution of tasks between remote systems.

REST APIs mostly use JavaScript Object Notation (JSON) files to compress and transfer data from one web application to another. JSON files are small, and therefore easier to transfer, and they are also a standard web file, which means the recipient browsers would be able to read the file without any assistance from the API.

What Is REST Security?

To achieve secure communication, REST APIs use Hypertext Transfer Protocol Secure (HTTPS). A Transport Layer Security (TLS) protocol ensures that the connection is private (by encrypting the data), authenticated (through public-key cryptography), and reliable (through the use of a message authentication code).

REST APIs are stateless. To complete a connection, a REST API doesn’t need the client or the server. The HTTP request takes care of that by gathering and saving any requested information. This means that if threat actors gain access to the HTTP request, they gain access to the data.

REST security practices and solutions are entrusted with ensuring that any connection achieved through REST APIs is secured. REST security practices provide a guideline for developing and securing the APIS (as explained below), and the security solutions support these efforts.

What Is OWASP REST Security Cheat Sheet?

The OWASP REST security cheat sheet is a document that contains best practices for securing REST API. Each section addresses a component within the REST architecture and explains how it should be achieved securely.

The table below summarizes the key best practices from the OWASP REST security cheat sheet. For more information, please refer to the official documentation.

Implementing the OWASP REST Security Cheat Sheet

Securing your REST API doesn’t have to be difficult or even time-consuming. Sometimes, it’s only a matter of assessing your situation and then applying the appropriate fixes. In the section above, we reviewed key REST security best practices. Now, we’re going to provide you with a few pro tips to help you secure your APIs.

1. Applying the HTTPS-only standard

HTTPS is enabled through the use of Secure Socket Layer (SSL) certificates. The first step is to buy a certificate from your host provider. Next, you will need to install the certificate. This is done through the hosting panel, and it’s as simple as following the steps provided by the host.

Making your site HTTPS-only means going through your directories (such as client libraries, code examples, and sample applications), and replacing the calls from HTTP with HTTPS. You can do this manually, which takes time, or you can use a free search-and-replace tool.

2. Using an Identity Provider (IdP) for tokens

An IdP is a system that controls the process of creating and managing identity information and provides authentication services such as tokens generation. A token is a meaningless sequence of characters that replaces sensitive and financial information.

The IdP receives a request from the website to tokenize the information. Then, the system saves the information in a secure location and replaces it with a token. The IdP mediates between the user and the website, keeping the information safe in a third-party repository. You can find a list of IdPs here.

3. Cryptographic signatures for JWT

Digital signatures provide integrity, authentication, and non-repudiation, which makes them ideal for issuing tokens. You can delegate the task of generating tokens to an IdP (as explained above) or you can do this manually through the use of a verified OAuth 2.0 server.

You can build your own OAuth server, use the OAuth server sponsored by OKTA, and you can use open-source solution. Before committing to a path, assess your situation honestly, and ensure that you have the skills and resources to do this on your own.

4. Add the 429 HTTP return code for too many requests

The purpose of the 429 return code is to prevent repeated API requests. It’s up to you to determine how many requests are too many in any given time, but this return code is a must. It provides you with a mechanism to provide DDoS attacks, which could cause a system outage.

Here’s a 429 code example from the RFC documentation:

Remember: never use a cache to store 429 status codes(!)

5. Use Cross-Origin Resource Sharing (CORS) for restricting HTTP methods

CORS is a technique that provides controls for sharing resources. That means you can use CORS to configure when access to HTTP methods should be granted or denied when it should be restricted, and what credentials and origins are authorized.

Be sure to research the subject, and configure your CORS properly. You can find a tutorial here, and here. If you don’t want to build from scratch, you can use this open-source CORS proxy. Be sure to test the code before running it, to make sure it’s as bug-free as possible.

It’s a Wrap!

In today’s hyper-connected world, there’s hardly any system that functions without an API. Networks, web applications, and IoT devices rely on their APIs for communication. An IoT device loses its meaning without an API. A web application can’t access data without an API, and endpoints can’t connect to networks without APIs.

REST APIs are entrusted with the communication between web applications. As most systems run web applications, insecure REST APIs could lead to breaches. A threat actor can cause a lot of damage by hacking only one REST API. To avoid a REST API breach, implement the OWASP REST security best practices and keep your APIs as secure as possible.

Author Bio

Gilad David Maayan is a technology writer who has worked with over 150 technology companies including SAP, Samsung NEXT, NetApp and Imperva, producing technical and thought leadership content that elucidates technical solutions for developers and IT leadership.

LinkedIn: https://www.linkedin.com/in/giladdavidmaayan/

An API, or Application Programming Interface, is how software talks to other software. Every day, the variety of APIs and the volume of API calls are growing. Every web and mobile application out there is powered by APIs. By nature of the APIs, many of them have a direct line to the heart of the user data and the application logic.

For example, getting control of the billing API would allow a hacker to redirect payments to his/her own accounts or mark purchases as completed, while the actual payment has not been received. Substituting a malicious or phishing API for a legitimate one can result in whole sites being taken over. We have seen catastrophic results of such actions in the recent security issues around cryptocurrency exchanges where hundreds of millions of dollars were lost.

Here at RestCase, we believe that the best security is preventive security. When we auto-generate security tests for your API, the first thing we are testing is the Man-In-The-Middle attack.

I more than welcome anyone who wants to check out the RestCase platform and our API testing - Create a project, API and start testing within seconds. Register for Free!

Let's go over this in-depth and see how can we prevent this attack from happening.

Man-In-The-Middle Attack (MITM)

‘Man-In-The-Middle’ attacks are when an unauthorized third-party secretly altering, intercepting or relaying communications between two interacting systems and intercept the private and confidential data passed between them.

MITM attacks occur in two stages: interception and decryption.

Here are 2 recommendations that will make your REST API more secure:

1. HTTP and Lack of TLS

The absence of a Transport Layer Security (TLS) in an API is practically equivalent to handing out open invitations to hackers. Transport layer encryption is one of the most elementary ‘must-haves’ in a secure API.

What is TLS?

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communications security over a computer network.

When secured by TLS, connections between a client and a server have one or more of the following properties:

• The connection is private (or secure) because symmetric cryptography is used to encrypt the data transmitted.
• The keys for this symmetric encryption are generated uniquely for each connection and are based on a shared secret negotiated at the start of the session.
• The identity of the communicating parties can be authenticated using public-key cryptography.
• The connection ensures integrity because each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission.

Unless a TLS is used, risks of the fairly common ‘Man-In-The-Middle’ attacks remain very high. Use both SSL and TLS in your APIs, especially if you are going public with your APIs. Today, you can get a free certificate with Let's Encrypt.

SSL and TLS go a long way in removing basic API vulnerabilities with almost minimal effort.

To get an excellent report on how good your implementation is, run your URL against the Qualys SSL server test. Here is ours:

2. Use Strict Transport Security

Forcing SSL should be combined with HTTP Strict Transport Security. Otherwise, you run a risk of users entering your domain without specifying a protocol.

For example, typing example.com rather than https://example.com and then being redirected to HTTPS. This redirect opens a security hole because there’s a short time when communication is still over HTTP.

You can address this by sending an STS header with your response. This forces the browser to do the HTTP to HTTPS conversion without issuing a request at all. Instead, it sends the header together with a time setting that the browser stores, before checking again:

strict-transport-security:max-age=315360000; includeSubdomains

This means that the header is set for 10 years and includes all subdomains.

If you follow this simple two guidelines, it will make your REST API much more secure and less vulnerable to attacks.

While there are as many proprietary authentication methods as there are systems which utilize them, they are largely variations of a few major approaches. In this post, I will go over the 4 most used in the REST APIs and microservices world.

Authentication vs Authorization

Before I dive into this, let's define what authentication actually is, and more importantly, what it’s not. As much as authentication drives the modern internet, the topic is often conflated with a closely related term: authorization.

The two functions are often tied together in single solutions, but the easiest way to divide authorization and authentication is to ask: what do they actually state or prove about me?

Authentication is when an entity proves an identity. In other words, Authentication proves that you are who you say you are. This is like having a driver license which is given by a trusted authority that the requester, such as a police officer, can use as evidence that suggests you are in fact who you say you are.

Authorization is an entirely different concept and in simple terms, Authorization is when an entity proves a right to access. In other words, Authorization proves you have the right to make a request. Consider the following - You have a working key card that allows you to open only some doors in the work area, but not all of them.

In summary:
Authentication: Refers to proving correct identity
Authorization: Refers to allowing a certain action

An API might authenticate you but not authorize you to make a certain request.

Now that we know what authentication is, let's see what are the most used authentication methods in REST APIs.

4 Most Used Authentication Methods

Let's review the 4 most used authentication methods used today.

1. HTTP Authentication Schemes (Basic & Bearer)

The HTTP Protocol also defines HTTP security auth schemes like:

• Basic
• Bearer
• Digest
• OAuth
  and others...

We will go over the two most popular used today when discussing REST API.

Basic Authentication

HTTP Basic Authentication is rarely recommended due to its inherent security vulnerabilities.

This is the most straightforward method and the easiest. With this method, the sender places a username:password into the request header. The username and password are encoded with Base64, which is an encoding technique that converts the username and password into a set of 64 characters to ensure safe transmission.

This method does not require cookies, session IDs, login pages, and other such specialty solutions, and because it uses the HTTP header itself, there’s no need to handshakes or other complex response systems.

Here’s an example of a Basic Auth in a request header:
Authorization: Basic bG9sOnNlY3VyZQ==

Bearer Authentication

Bearer authentication (also called token authentication) is an HTTP authentication scheme that involves security tokens called bearer tokens.

The name “Bearer authentication” can be understood as “give access to the bearer of this token.” The bearer token allowing access to a certain resource or URL and most likely is a cryptic string, usually generated by the server in response to a login request.

The client must send this token in the Authorization header when making requests to protected resources:
Authorization: Bearer <token>

The Bearer authentication scheme was originally created as part of OAuth 2.0 in RFC-6750 but is sometimes also used on its own.

Similarly to Basic authentication, Bearer authentication should only be used over HTTPS (SSL).

2. API Keys

In REST API Security - API keys are widely used in the industry and became some sort of standard, however, this method should not be considered a good security measure.

API Keys were created as somewhat of a fix to the early authentication issues of HTTP Basic Authentication and other such systems. In this method, a unique generated value is assigned to each first time user, signifying that the user is known. When the user attempts to re-enter the system, their unique key (sometimes generated from their hardware combination and IP data, and other times randomly generated by the server which knows them) is used to prove that they’re the same user as before.

Many API keys are sent in the query string as part of the URL, which makes it easier to discover for someone who should not have access to it. Please do not put any API keys or sensitive information in query string parameters! A better option is to put the API key in the Authorization header. In fact, that’s the proposed standard: Authorization: Apikey 1234567890abcdef.

Yet, in practice API keys show up in all sorts of places:

• Authorization Header
• Basic Auth
• Body Data
• Custom Header
• Query String

There are definitely some valid reasons for using API Keys. First and foremost, API Keys are simple. The use of a single identifier is simple, and for some use cases, the best solution. For instance, if an API is limited specifically in functionality where “read” is the only possible command, an API Key can be an adequate solution. Without the need to edit, modify, or delete, security is a lower concern.

The problem, however, is that anyone who makes a request to a service, transmits their key and in theory, this key can be picked up just as easy as any network transmission, and if any point in the entire network is insecure, the entire network is exposed.

If you are dealing with Authentication in REST APIs, please consider doing Security Testing, in order to check the common vulnerabilities.

3. OAuth (2.0)

The previous versions of this spec, OAuth 1.0 and 1.0a, were much more complicated than OAuth 2.0. The biggest change in the latest version is that it’s no longer required to sign each call with a keyed hash. The most common implementations of OAuth use one or both of these tokens instead:

• access token: sent like an API key, it allows the application to access a user’s data; optionally, access tokens can expire.
• refresh token: optionally part of an OAuth flow, refresh tokens retrieve a new access token if they have expired. OAuth2 combines Authentication and Authorization to allow more sophisticated scope and validity control.

OAuth 2.0 is the best choice for identifying personal user accounts and granting proper permissions. In this method, the user logs into a system. That system will then request authentication, usually in the form of a token. The user will then forward this request to an authentication server, which will either reject or allow this authentication. From here, the token is provided to the user, and then to the requester. Such a token can then be checked at any time independently of the user by the requester for validation and can be used over time with strictly limited scope and age of validity.

This is fundamentally a much more secure and powerful system than the other approaches, mainly because it allows for the establishment of scopes which can provide access to different parts of the API service and since the token is revoked after a certain time - makes it much harder to re-use by attackers.

OAuth 2.0 Popular Flows

The flows (also called grant types) are scenarios an API client performs to get an access token from the authorization server.

OAuth 2.0 provides several popular flows suitable for different types of API clients:

• Authorization code – The most common flow, mostly used for server-side and mobile web applications. This flow is similar to how users sign up into a web application using their Facebook or Google account.
• Implicit – This flow requires the client to retrieve an access token directly. It is useful in cases when the user’s credentials cannot be stored in the client code because they can be easily accessed by the third party. It is suitable for web, desktop, and mobile applications that do not include any server component.
• Resource owner password – Requires logging in with a username and password. Since in that case, the credentials will be a part of the request, this flow is suitable only for trusted clients (for example, official applications released by the API provider).
• Client Credentials – Intended for the server-to-server authentication, this flow describes an approach when the client application acts on its own behalf rather than on behalf of any individual user. In most scenarios, this flow provides the means to allow users to specify their credentials in the client application, so it can access the resources under the client’s control.

4. OpenID Connect

OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, which allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner.

In technical terms, OpenID Connect specifies a RESTful HTTP API, using JSON as a data format.

OpenID Connect allows a range of clients, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, supporting optional features such as encryption of identity data, the discovery of OpenID Providers, and session management.

OpenID Connect defines a sign-in flow that enables a client application to authenticate a user, and to obtain information (or "claims") about that user, such as the user name, email, and so on. User identity information is encoded in a secure JSON Web Token (JWT), called ID token.

- JWT

JSON Web Tokens are an open, industry-standard RFC 7519 method
for representing claims securely between two parties. JWT allows
you to decode, verify and generate JWT. While JWT is a standard it
was developed by Auth0, an API driven identity, and authentication
management company.

OpenID Connect defines a discovery mechanism, called OpenID Connect Discovery, where an OpenID server publishes its metadata at a well-known URL, typically https://server.com/openid-configuration.

This URL returns a JSON listing of the OpenID/OAuth endpoints, supported scopes and claims, public keys used to sign the tokens, and other details. The clients can use this information to construct a request to the OpenID server. The field names and values are defined in the OpenID Connect Discovery Specification.

OpenAPI Security Schemes

In OpenAPI specification, in order to define what kind of a security mechanism is used across the API - API security schemes are used to define what API resources are secured and what means.

In OpenAPI specification there are a number of standard authentication protocols you can pick from, each with their own strengths and weaknesses.

Basic API Authentication

• Easy to implement, supported by nearly all web servers
• Entails sending base-64 encoded username and passwords
• Should not be used without SSL
• Can easily be combined with other security methods

Note: basic authentication is very vulnerable to hijacks and man-in-the-middle attacks when no encryption is in use. Due to this limitation, this method of authentication is only recommended when paired with SSL.

OAuth1.0 (Digest Scheme)

• Popular, tested, secure, signature driven, well-defined protocol
• Uses cryptographic signature, which is a mix of a token secret, nonce, and other request based information
• Can be used with or without SSL

OAuth2 (Bearer Token Scheme)

• The current OAuth2 specification eliminates the need for cryptographic signatures, passwords, and usernames
• OAuth2 works with authentication scenarios called flows, these flows include:
  • Authorization Code flow
  • Implicit flow
  • Resource Owner Password flow
  • Client Credentials flow

OpenID Connect Discovery

• Based on the OAuth 2.0 protocol
• Uses a sign-in flow that permits user authentication and information access by a client app
• The user information is encoded via a secure JSON Web Token (JWT)

RestCase development platform, allows you to define these Security schemes visually, allowing to build and define the entire API without any coding knowledge.

Please feel free to join our Beta, just sign-up and start building APIs - It's free!

Summary

For now, the clear winner of the four methods is OAuth 2.0, there are some use cases in which API keys or HTTP Authentication methods might be appropriate and the new OpenID connect is getting more and more popular, mainly because it is based on an already popular OAuth 2.0.

OAuth 2.0 delivers a ton of benefits, from ease of use to a federated system module, and most importantly offers scalability of security – providers may only be seeking authentication at this time, but having a system that natively supports strong authorization in addition to the baked-in authentication methods is very valuable, and decreases cost of implementation over the long run.

OpenAPI has become the industry standard for defining an API, yet it is often treated as a documentation tool only.

Here at RestCase, we are using the OpenAPI specification for supporting and drive many parts of your API lifecycle development because we believe that REST is mostly about a contract between the provider and the consumer of the API. And, if a contract - Then it should be a written contract that many understands.

Here is were OpenAPI specification comes to play!

What is OpenAPI Specification?

The OpenAPI Specification (OAS) and formerly known as Swagger. defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to the source code, documentation, or through network traffic inspection.

When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.

An OpenAPI definition can then be used by documentation generation tools to display the API, code generation tools to generate server SDKs and client CDKs in various programming languages, testing tools, and many other use cases.

API Documentation with OpenAPI

Generating documentation for your API is just one of the advantages of defining your API with OpenAPI.

Other benefits include:

• Help different team members develop the API, understand it and agree on its attributes.
• Help external stakeholders understand the API and what they can do with it.

There are many documentation tools you can use in order to visualize your API definitions.

Here are some of the tools available:

• LucyBot - Generate a customizable website, with API documentation, console, and interactive workflows, from an OpenAPI spec.
• ReDoc - OpenAPI/Swagger-generated API Reference Documentation
• WidderShins - Beautiful static documentation for your API.
• RapiDoc - Web Component for OpenAPI Spec Viewing. Create beautiful, customizable, interactive API documentation from your OpenAPI Specification.

But OpenAPI is not just about documentation. Let's see other advantages and usages for the OpenAPI definitions and why it is worth to create one for your API.

Design-First Development (Specification-First)

Although you can generate your specification document from code annotations, many say that auto-generation is not the best approach. In Undisturbed REST: A Guide to Designing the Perfect API, Michael Stowe recommends that teams implement the specification by hand and then treat the specification document as a contract that developers use when doing the actual coding. This approach is often referred to as “Design-First Development” or “Documentation Driven API Design”.

With this approach, developers consult the specification document to see what the parameter names should be called, what the responses should be, and so on. After this contract has been established, Stowe says you can then put the annotations in your code to auto-generate the specification document.

Too often, development teams quickly jump to coding the API endpoints, parameters, and responses without doing much user testing or research into whether the API aligns with what users want.

Since versioning APIs is extremely difficult (you have to support each new version going forward with full backward compatibility to previous versions), you want to avoid the “fail fast” approach that is so commonly celebrated with agile.

There’s nothing worse than releasing a new version of your API that invalidates endpoints or parameters used in previous releases.

The design-first approach helps distribute the documentation work to more team members than engineers. Defining the OAS specification before coding also helps teams produce better APIs.

Even before the API has been coded, your spec OAS specification can be used to generate a mock response by different tools available or by adding response definitions within your OAS specification.

There are some very nice Visual OpenAPI Editors you can use in order to speed the development of your API:

• ApiBldr - Visual OpenApi Builder - UI Tool For Building API Specification (OpenAPI / Swagger).
• Apicurio Studio - A standalone API design studio that can be used to create new or edit existing API designs.
• OpenAPI-GUI - GUI / visual editor for creating and editing OpenAPI / Swagger definitions

Mocking a new API

An API specification, like we already went through, is a fantastic tool for early prototyping an API. It helps us define a schema, ways to interact with resources, pretty much all the foundational API ‘things’ we need.

There are plenty of mocking tools out there, because you don’t have to write code, using an API specification can shorten the time for feedback on your new API from days or hours, to several minutes.

Here are some of the API mocking tools there are for OpenAPI:

• Connexion - Connexion is a framework on top of Flask that automagically handles HTTP requests defined using OpenAPI (formerly known as Swagger), supporting both v2.0 and v3.0 of the specification. Connexion allows you to write these specifications, then maps the endpoints to your Python functions.
• Microcks - Directly import your OpenAPI specification as a Job within Microcks. Then, it directly discovers service definition as well as request/response samples defined as OpenAPI examples. If your specification embeds a JSON or OpenAPI schema definition for your custom datatypes, Microcks will use it for validating received response payload during tests when using the OPENAPISCHEMA strategy.
• FakeIt - Create mock server from Openapi specification. It supports randomly generated response, requests validation and more.
• APISprout - A simple, quick, cross-platform API mock server that returns examples specified in an API description document. Among the features, it supports OpenAPI 3.x, CORS, Server validation and more.

Implementing an API using Code Generators

If you’re using a spec to get early feedback on your API design, you’re more likely to have a stable API definition when the time comes to implementing it.

In addition to generating documentation, the OpenAPI definition can also be used to accelerate development by scaffolding implementation code and SDKs for the API. It will give you the REST API skeleton project stubs code in many different languages, like Java, Scala, and others and will allow you to save valuable time.

Here are some of the free Code Generators available:

• OpenAPI Generator - Generate clients, servers, and documentation from OpenAPI 2.0/3.x documents
• GuardRail - Principled code generation from OpenAPI specifications
• Swagger-Codegen - Contains a template-driven engine to generate documentation, API clients and server stubs in different languages by parsing your OpenAPI / Swagger definition.

API Testing

Once you have an OpenAPI definition, you can quickly create tests and validate the API specifications against the backend implementation of the same API.

The OpenAPI definition provides a contract that describes what a successful response will look like when someone calls your API. This contract can also be re-purposed to generate test cases which can drastically decrease the amount of setup team needed for testing your APIs.

If you create your REST-API contract-first without using any type of generation, you have to make sure that specification and implementation don't diverge.

Here are some of the tools one can use in order to quickly execute API request and validate responses on the fly:

• OpenAPI-Validator - Validate data against OpenAPI v3 specification.
• Hikaku - A library that tests if the implementation of a REST-API meets its specification. The aim of this project is to meet this need and offer a mechanism to check specification and implementation for equality without having to create requests which are fired against a mock server. So this library won't check the behavior of the API, but the structural correctness.
• Dredd - Dredd is a language-agnostic command-line tool for validating API description document against backend implementation of the API.

Summary

I have shown that OpenAPI is not only documentation. The OpenAPI Specification has a whole world of uses and if used correctly it can be a huge asset! With it, you can leverage your API to generate client and server code, do automated testing and much much more!

Want to take your API to the next level? Then you should give your API an OpenAPI specification!

Internet security is a topic which has been discussed increasingly quite often by technology blogs and forums and with valid reason: the numerous high profile security breaches have grown up significantly in recent years. Security is of great importance, especially in the world of REST APIs.

API security is the single biggest challenge organizations want to see solved in the years ahead, and solving the security challenge is expected to be a catalyst for growth in the API world.

According to the 2018 State of API integration report by Jitterbit:

APIs are Transforming Business

An impressive 64% of organizations are creating APIs today for use in either internal or external use cases. While a quarter of the respondents are not creating APIs at all today, 40% are leveraging APIs in both internal and external use cases.

API Creation and Management is Falling to Developers

A majority of organizations leveraging APIs today rely on their developers to both write and manage these APIs. While 33% use dedicated technology to manage their APIs, 90% of respondents lean on their development teams or outside resources to code APIs from scratch.

Already burdened with coding integrations between an increasing number of new cloud applications, organizations are placing additional demands on their developers to create and manage APIs for the business.

Security of REST API

Securities issues must be an important aspect to consider any time REST API is been design, testing, and deploying. With the mind-blowing development of REST APIs, the security levels most times are underestimated in the design and development of the API. Security of sensitive data, be it organizational or personal information, is an important factor troubling developers and everybody nowadays. REST APIs is not an exception, being part of essential systems that require protection against security threats and breaches.

According to the 2018 Postman community report (survey), more developers are paying attention to REST API security and have higher confidence than the year before:

In this post, I will cover the top 7 REST API security threats in today’s IT world in order to get everyone's attention and assist in being aware of the security threats that have the capability to reflect on the performance of REST APIs.

Security concerns with REST

REST typically uses HTTP as its underlying protocol, which brings forth the usual set of security concerns:

• A potential attacker has full control over every single bit of an HTTP request or HTTP response. Since REST APIs are commonly used in order to exchange information which is saved and possibly executed in many servers, it could lead to many unseen breaches and information leaks.
• The attacker could be at the client side (the consumer of your REST API and, where the victim is the REST API server) or at the server side (the attacker gained control over your REST API server) where he creates a rogue, malicious app. The victim, in this case, is the application consuming resources from your remote REST API services.
• For an application using REST as client or server, the other side typically has full control on the resource representation, and could inject any payload to attack resource handling (gaining arbitrary Java code or system command execution, for example).

In a REST architecture, end-to-end processing implies a sequence of potentially vulnerable operations:

• During the mapping from/to the HTTP message and resource URL (controller mapping).
• When the object representing the target resource is instantiated and the requested operation is invoked (calling the services from the controller).
• When producing state representation for the target resources (the services specific function).
• When accessing/modifying the data in the backend systems that host the resource state (saving into the DB or storage).

The layered sequence of transformations in REST frameworks means that a single weak link in the chain could make your application vulnerable.

The TOP 7 REST API Security Threats

1. Injection Attacks

In an injection attack, a dangerous code is embedded into an unsecured software program to stage an attack, most notably SQL injection and cross-site scripting. This exposure could, in fact, be manipulated by transferring untrusted data into the API as part of a query or command. The input is subsequently implemented by the interpreter which can result in an attacker obtaining unauthorized access to information or carry out other damages.

The most effective way to stop or deny an injection attack is by adding input validation, here are the most crucial guidelines:

• Validate input: length / range / format and type
• Achieve an implicit input parameters validation by using strong types like numbers, booleans, dates, times or fixed data ranges in API parameters
• Constrain string inputs with regex
• Define an appropriate request size limit and reject requests exceeding the limit with HTTP response status 413 Request Entity Too Large

2. DoS Attacks

In a Denial of Service (DoS) attack, the attacker in most cases pushes enormous messages requesting the server or network to establish requests consisting of invalid return addresses. The attack is capable of rendering a RESTful API into a non-functional situation if the appropriate security precautions are not adopted. In recent times, whether your API is exposed or not, it could possibly be accessible by other people (attackers inclusive).

As these API DoS attacks become more common, and as organizations increasingly rely on APIs for their business needs, security professionals should proactively plan to deal with such attacks. Even if an API key (or access token) used for application authentication is disabled, a key can easily be reacquired through a standard browser request. Therefore, invalidating a current access token is not a long-term solution. If a DoS attack is traced back to a specific IP address, then blacklisting that IP address isn't a long-term solution either, because the attacker can easily acquire a new one.

That's why multiple access control methods are necessary. For non-sensitive information, the use of API keys might be sufficient. However, to better prevent a DoS attack, the use of HTTPS and more robust authentication mechanisms, including OAuth, mutual (two-way) TLS (transport layer security) authentication, or SAML (security assertion markup language) tokens, are necessary.

To prevent a massive amount of API requests that can cause a DDoS attack or other misuses of the API service, apply a limit to the number of requests in a given time interval for each API (also called spike arrest). When the rate is exceeded, block access from the API key at least temporarily, and return the 429 (too many requests) HTTP error code.

In case you are starting to build your new REST API check for web servers that have many security-oriented features.

3. Broken Authentication

These particular problems can make an attacker to either bypass or take control of the authentication methods made use of by a web program. Missing or inadequate authentication can result in attack whereby JSON web tokens, API keys, passwords, etc. can be compromised. The aim of the attack is usually to take charge of several accounts, not to mention the attacker getting the equal privileges as the attacked user. Solely authenticated users should be given access to the APIs.

The APIs authorization and authentication requirements could very well be taken care of using OpenId/OAuth tokens, PKI, API key. It would be wise never to send credentials over connections that are not encrusted, also don’t reveal session ID in the Web URL.

4. Sensitive Data Exposure

Exposure of sensitive data caused by lack of encryption in transit or at rest may result in an attack. Sensitive Data Exposure happens whenever an application is unable to properly secure sensitive data. The information can differ from private health information to credit card information, session tokens, passwords and a lot more tend to be venerable to attack. Sensitive data requires high security which includes encryption at rest or in transit, in addition to extraordinary safe practices when exchanged with the browser.

In order to avoid exposing sensitive data, you must use an SSL.
Today, you can get a free certificate with Let's Encrypt. SSL and TLS go a long way in removing basic API vulnerabilities with almost minimal effort.

To get an excellent report on how good your implementation is, run your URL against the Qualys SSL server test. Here is ours:

5. Broken Access Control

Access control, in some cases known as authorization, is how a web software allows access to functions and contents to certain people rather than everybody. Missing or inadequate access control can permit the attacker to gain control of other users accounts, alter access privileges, change data etc.

Company application access tends to attack when operational level accessibility is not configured properly by developers leading to access vulnerabilities. Declined access is the best-known consequence of broken access controls and exploitation of access control is the main craft of attackers.

Access control is detectable making use of manual means, or even via automation for the lack of access controls in some frameworks. Access control is usually productive if implemented in reliable server-less or server-side API, whereby the attacker won't be able to alter the access control metadata.

6. Parameter Tampering

It’s an attack that is based on the manipulation of parameters exchanged between client and server in order to modify application data, such as user credentials and permissions, price and quantity of products, etc. Usually, this information is stored in cookies, hidden form fields, or URL query strings, and is used to increase application functionality and control.

This happens when a harmful website, program, instant message, blog or e-mail makes a user’s internet browser to carry out an unnecessary action on an authorized site. It allows an attacker to makes the targeted system to carry out a function using the target's web browser, unknowingly to the attacked user, perhaps until the not authorized transaction has been carried out.

The attack success depends on integrity and logic validation mechanism errors, and its exploitation can result in other consequences including XSS, SQL Injection, file inclusion, and path disclosure attacks.

You should carefully validate URL parameters received, to ensure the data represents a valid request from the user. Invalid requests can be used to attack the API directly or targeting the application and systems behind the API. Put validators on the application and try to use API Signing for the requests sent to the REST API. It is also good to create automatic security tests for your API in order to see that no parameter tampring affects your REST API.

7. Man-In-The-Middle-Attack (MITM)

It’s when an attacker secretly altering, intercepting or relaying communications between two interacting systems and intercept the private and confidential data pass between them. MITM attacks occur in two stages: interception and decryption.

HTTP and Lack of TLS

The absence of a Transport Layer Security (TLS) in an API is practically equivalent to handing out open invitations to hackers. Transport layer encryption is one of the most elementary ‘must-haves’ in a secure API. Unless a TLS is used, risks of the fairly common ‘Man-In-The-Middle’ attacks remain very high. Use both SSL and TLS in your APIs, especially if you are going public with your APIs.

Summary

When developing a REST API, you have to pay attention to security from the start. Consider using an existing API framework that has many of the security features built in. At RestCase, we are using SugoiJS API Framework that we also contribute to its codebase along with testing and security guiding. In this way, security is uniformly built in and developers can focus on the application logic.

After all that don’t neglect to allocate resources to test the security of the APIs. Make sure to test all the security threats mentioned in this post.

If you are building REST APIs or REST Services you're using HTTP.
Technically, REST services can be provided over any application layer protocol as long as they conform to certain properties. In practice, basically, everyone uses HTTP Protocol.

Since we are discussing the creation of an API that conforms to REST rather than a system architecture based on the principles of REST, HTTP is a solid assumption.

Roy Fielding writes:

A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations.

A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations.

These concepts are closely related to the notion of "hypermedia controls". The basic idea is that a representation of an object should tell the client what it can do with the object or related actions that it might take. Such descriptions are called "hypermedia controls". The format used to present hypermedia controls is specified by the media type.

The Richardson REST Maturity Model describes four different levels of REST (starting at Level 0). A REST API that supports hypermedia controls is classified as Level 3 in this maturity model.

The levels of maturity according to Richardson’s model:

However, all these are discussing the REST API maturity level and not the design maturity level.

When discussing the REST API maturity level design we have to think about the following: Versioning, Actions, Errors, Pagination and more. I will try to go over the basic maturity levels and add a REST API design perspective. For more information on some of the rules please read these as well:
7 Rules for REST API URI Design
5 Basic REST API Design Guidelines

Level 0 - The Swamp of POX

The Swamp of POX (Plain Old XML) means that you’re using HTTP. Technically, REST services can be provided over any application layer protocol as long as they conform to certain properties. In practice, basically, everyone uses HTTP.

These services have a single URI and use a single HTTP method (typically POST). These are the most primitive way of building SOA applications with a single POST method and using XML to communicate between services.

Level zero of maturity does not make use of any of URI, HTTP Methods, and HATEOAS capabilities.

Even at level 0, there are many design rules that we need to consider:

Rule #1: Hyphens (-) should be used to improve the readability of URIs - Also referred to as spinal-case

To make your URIs easy for people to scan and interpret, use the hyphen (-) character to improve the readability of names in long path segments. Anywhere you would use a space or hyphen in English, you should use a hyphen in a URI.

For example:
http://api.example.com/blogs/guy-levin/posts/this-is-my-first-post

It is recommended to use spinal-case (which is highlighted by RFC 3986), this case is used by Google, PayPal, and other big companies.

Rule #2: Underscores (_) should not be used in URIs

Text viewer applications (browsers, editors, etc.) often underline URIs to provide a visual cue that they are clickable. Depending on the application’s font, the underscore (_) character can either get partially obscured or completely hidden by this underlining.

To avoid this confusion, use hyphens (-) instead of underscores

Rule #3: Lowercase letters should be preferred in URI paths

When convenient, lowercase letters are preferred in URI paths since capital letters can sometimes cause problems. RFC 3986 defines URIs as case-sensitive except for the scheme and host components.

For example:
http://api.example.com/my-folder/my-doc vs http://api.example.com/My-Folder/my-doc

Rule #4: File extensions should not be included in URIs

On the Web, the period (.) character is commonly used to separate the file name and extension portions of a URI.
A REST API should not include artificial file extensions in URIs to indicate the format of a message’s entity body. Instead, they should rely on the media type, as communicated through the Content-Type header, to determine how to process the body’s content.

http://api.college.com/student/3248234/course/2005/fall.json http://api.college.com/student/3248234/course/2005/fall

Level 1 - Resources

REST’s ‘resources’ are the core pieces of data that your application acts on. These will often correspond to the Models in your application (especially if you’re following the MVC - model, view, controller pattern).

API design at Level 1 is all about using different URLs to interact with the different resources in your application.

First, I would like to clarify that using verbs in URI which is bad practice and I write then next only to demonstrate a point and to ease the way into the resources properly usage.

Let’s write few APIs for Blog which has some articles, to understand more. /getAllArticles is an API which will respond with the list of articles.

Few more APIs around a Blog will look like as follows:
/addNewArticle
/updateArticle
/deleteArticle
/deleteAllArticle
/promoteArticle
/promoteAllArticle

There are a set of common operations that are performed on resources, and it seems kinda silly to make a new URI for every operation, especially when they’re shared - That is where Level 2 comes in.

Even at this level, there are a few design rules that worth to remember:
Rule #1: A trailing forward-slash (/) should not be included in URIs

This is one the most important rules to follow as the last character within a URI’s path, a forward slash (/) adds no semantic value and may cause confusion. REST API’s should not expect a trailing slash and should not include them in the links that they provide to clients.

http://api.canvas.com/shape/ http://api.canvas.com/shape

Every character within a URI counts toward a resource’s unique identity.

Two different URIs map to two different resources.

Rule #2: Forward slash separator (/) must be used to indicate a hierarchical relationship

The forward-slash (/) character is used in the path portion of the URI to indicate a hierarchical relationship between resources.

For example:
http://api.canvas.com/shapes/polygons/quadrilaterals/squares

Rule #3: Should the endpoint name be singular or plural? The keep-it-simple rule applies here. Although your inner-grammatician will tell you it's wrong to describe a single instance of a resource using a plural, the pragmatic answer is to keep the URI format consistent and always use either plural or singular.

Not having to deal with odd pluralization (person/people, goose/geese) makes the life of the API consumer better and is easier for the API provider to implement (as most modern frameworks will natively handle /students and /students/3248234 under a common controller).

I personally like to use the singular way since for me, using it like GET /person and GET /person/{ID}, the first one means a search for a person without any ID which means - return every person and the second one is searching a person with a given ID. One more thing to consider is that when we talk about Resources in APIs, it is mostly a Resource (single) that is being manipulated - as you will see later on in the methods table, even if we say collection - it is not collections. But you are more than welcome to use either one, plural or singular, at your own choice - just be consistent!

Level 2 - Methods

We are always going to need to perform CRUD operations on our resources, so why not find a way to share these operations across resources? Why create a new resource for each action or operation we would like to perform?

We accomplish this using HTTP Verbs. If we want to get a list of Pages, we make a GET request to /page, but if we want to create a new Page, we use POST rather than GET to the same resource - /page.

Here is the common Methods / Actions used:

Actions

Sometimes, it is required to expose an operation in the API that inherently is non-RESTful. One example of such an operation is where you want to introduce a state change for a resource, but there are multiple ways in which the same final state can be achieved, and those ways actually differ in a significant but non-observable side-effect.

Some may say such transitions are bad API design, but not having to model all state can greatly simplify an API.

As a solution to such non-RESTful operations, an “actions” sub-collection can be used on a resource. Actions are basically RPC-like messages to a resource to perform a certain operation. The “actions” sub-collection can be seen as a command queue to which new action can be POSTed, that are then executed by the API. Each action resource that is POSTed, should have a “type” attribute that indicates the type of action to be performed and can have arbitrary other attributes that parameterize the operation.

It should be noted that actions should only be used as an exception when there’s a good reason that an operation cannot be mapped to one of the standard RESTful methods.

Level 2.1 - HTTP headers

The HTTP headers are one of the basic design rules for REST APIs. They are needed in order to convey more data about the resource itself, mostly meta-data, security, hashes and more.

HTTP headers also provide the required information about the request or response, or as we said - about the object sent in the message body.

There are 4 types of HTTP message headers:

General Header These header fields have general applicability for both request and response messages.

Client Request Header These header fields have applicability only for request messages.

Server Response Header These header fields have applicability only for response messages.

Entity Header These header fields define meta information about the entity-body or, if no BODY is present, about the resource identified by the request.

Level 2.2 - Query Parameters

Another important part of REST API design is using query parameters.
They are widely used in many cases but it is more likely that they are used in order to achieve some sort of searching, filtering, and querying.

Paging It is necessary to anticipate the paging of your resources in the early design phase of your API. It is indeed difficult to foresee precisely the progression of the amount of data that will be returned. Therefore, we recommend paginating your resources with default values when they are not provided by the calling client, for example with a range of values [0-25].

Filtering Filtering consists in restricting the number of queried resources by specifying some attributes and their expected values. It is possible to filter a collection on several attributes at the same time and to allow several values for one filtered attribute.

Sorting Sorting the result of a query on a collection of resources. A sort parameter should contain the names of the attributes on which the sorting is performed, separated by a comma.

Searching A search is a sub-resource of a collection. As such, its results will have a different format than the resources and the collection itself. This allows us to add suggestions, corrections, and information related to the search.

Level 2.3 - Status Codes

It is very important that as a RESTful API, you make use of the proper HTTP Status Codes, especially when developing and mocking RESTful API.

The mostly used status codes:

200 – OK
Everything is working

201 – CREATED
A new resource has been created

204 – NO CONTENT
The resource was successfully deleted, no response body

304 – NOT MODIFIED
The date returned is cached data (data has not changed)

400 – BAD REQUEST
The request was invalid or cannot be served. The exact error should be explained in the error payload. E.g. „The JSON is not valid “.

401 – UNAUTHORIZED
The request requires user authentication.

403 – FORBIDDEN
The server understood the request but is refusing it or the access is not allowed.

404 – NOT FOUND
There is no resource behind the URI.

500 – INTERNAL SERVER ERROR
API developers should avoid this error. If an error occurs in the global catch blog, the stack trace should be logged and not returned as a response.

Level 3 - Hypermedia Controls

This level is the one that everyone falls down on. There are two parts to this: content negotiation and HATEOAS. Content negotiation is focused on different representations of a particular resource, and HATEOAS is about the discoverability of actions on a resource.

Content Negotiation

Generally, resources can have multiple presentations, mostly because there may be multiple different clients expecting different representations. Asking for a suitable presentation by a client is referred to as content negotiation.

HTTP has provisions for several mechanisms for “content negotiation” — the process of selecting the best representation for a given response when there are multiple representations available.

Content Negotiation is performed by an application:

To match the requested representation as specified by the client via the Accept header with a representation the application can deliver.
To determine the Content-Type of incoming data and deserialize it so the application can utilize it.

Essentially, content negotiation is the client telling the server what it is sending and what it wants in return, and the server determining if it can do what the client requests.

Accept Negotiation

The first aspect of content negotiation is handling the Accept header. The Accept header has one of the most complex definitions in the HTTP specification. With supplying this header in the request, a client can indicate a prioritized list of different media types that it will accept as responses from the server.

In practice, particularly with APIs, you will send a specific media type for the representation you can handle in your client. As an example:

GET /foo HTTP/1.1 Accept: application/json
The above indicates that the client wants JSON for a response. It is now the server's responsibility to determine if it can return that representation.

If the server can not return JSON, it needs to tell the client that fact. This is done via the 406 Not Acceptable status code:

HTTP/1.1 406 Not Acceptable Ideally, the server will also indicate what media types it can return; however, it is not obligated to do so.

Because the server cannot return a representation for the requested media type, it can choose whatever media type it wants for the response in order to communicate errors.

If the server can return the requested media type, it should report the media type via the response Content-Type header.

One important point of interest: the same URI can potentially respond with multiple media types. This means that you could potentially make one request that specifies text/html, another with application/json, and get different representations of the same resource!

This is a very important aspect of content negotiation; one of the purposes is to allow many clients to the same resource, speaking in different protocols.

Content-Type Negotiation

The second aspect of content negotiation is identifying the incoming Content-Type header and determining if the server can deserialize that data.

As an example, the client might send the following:

POST /foo HTTP/1.1
Accept: application/json
Content-Type: application/json
{ "foo": "bar" }

The server would introspect the Content-Type header and determine that JSON was submitted. Now it has to decide if it can deserialize that content. If it cannot, the server will respond with a 415 Unsupported Media Type status code:

HTTP/1.1 415 Unsupported Media Type

If the data submitted is not actually of the Content-Type specified, meaning it cannot be deserialized properly, the server will typically respond with a generic 400 Bad Request status.

HATEOAS

Hypermedia As Transfer Engine Of Application State is a constraint of the REST application architecture that distinguishes it from other network application architectures.

It provides ease of navigation through a resource and its available actions. This way a client doesn’t need to know how to interact with an application for different actions, as all the metadata will be embedded in responses from the server.

To understand it better let’s look at the below response of retrieve user with id 123 from the server:

{ "name": "John Doe", "links": [{ "rel": "self", "href": "http://localhost:8080/user/123" }, { "rel": "posts", "href": "http://localhost:8080/user/123/post" }, { "rel": "address", "href": "http://localhost:8080/user/123/address" } ] }

Sometimes it’s easier to skip the links format, and specify links as fields of a resource as below:

{ "name": "John Doe", "self": "http://localhost:8080/user/123", "posts": "http://localhost:8080/user/123", "address": "http://localhost:8080/user/123/address" }

It’s not a convention you need to follow every time, as it depends on resource fields/size, and actions which can be performed on a resource. If resources contain several fields that the user may not want to go through, it’s a good idea to show navigation to sub-resources then implement HATEOAS.

3.1 - Versioning

I have decided to include the versioning design here since REST API versioning is a much more mature REST API model and for the reason that Content negotiation is focused on different representations of a particular resource, versioning can be called as a different representation of a resource.

Versioning APIs always helps to ensure backward compatibility of a service while adding new features or updating existing functionality for new clients.

There are different schools of thought to version your API, but most of them fall under two categories below:

Headers:

There are 2 ways you can specify the version in headers:

Custom Header:

Adding a custom X-API-VERSION (or any other header of choice) header key by the client can be used by a service to route a request to the correct endpoint

Accept Header

Using accept header to specify your version such as

Accept: application/vnd.hashmapinc.v2+json

URL:

Embed the version in the URL such as

POST /v2/user

I prefer to use the URL method for versioning as it gives better discoverability of a resource by looking at the URL.

Summary

In this article, I have tried to reflect the REST API design rules on the Richardson Maturity Model for REST API's. There are many talks about the 4 levels of REST API maturity, however they are not complete in my opinion as they are only showing usages of Resources, Methods, and Content Negotiation / HATEOAS but they are not saying anything about the usages of HTTP Headers, Status Codes, Query parameters, and other REST API design aspects.

So you've decided that you want to deploy a NodeJS application on Azure Web App, but all of the official (and well documented) guides use GitHub/Bitbucket/FTP it seems like no one uses Azure DevOps (previously VSTS), or is it?

Here is a small overview of Azure DevOps :

I am going to use Azure Pipelines in order to create a build and deploy it to Azure.

Creating a NodeJS application

To deploy an application we, first, need an application. Before we can have an application we need a project in the Azure DevOps.

To create a project simply click the Create button once you get to the Azure DevOps portal.

I have created a simple Hello World application in there that is listening on port 3000.

server.ts file:

import * as express from "express";

const app = express()  
let port = 3000;  
if (process.env.PORT !== undefined) {  
  port= process.env.PORT;
}

app.get('/', (req, res) => res.send('Hello World!'))

app.listen(port, () => console.log(`Example app listening on port ${port}!`))  

The example is taken from http://expressjs.com/en/starter/hello-world.html

In this case, I'm using Gulp for compiling Typescript and for creating source maps. But any other build tool/pipeline may be used instead.

For local REST API development and debugging, in the content of the server.ts file, I am using the port 3000. This will need to be overridden as in the Azure WebApp the listening port is given by the PORT environment variable.

Create the build pipeline

Going into your Azure DevOps dashboard and then into Pipelines and the Builds subsection.

Just click the New Pipeline button and create a mapping for your exact project folder and hit Continue

You will be greeted with a menu that asks you to map the project folder to a working directory.
As I am going to build and release the Portal project, I will map it directly to the working directory.

After the mapping, you will be greeted with a template selection

As of this writing, there are two build templates:

• Node.js with gulp
• Node.js with grunt

As I've used Gulp in our new application, so the Gulp template is the one I am going to choose. In any case, you can choose an Empty Pipeline template if you can't find a template that fits your needs.

Configuring the build pipeline

Once you have created the pipeline, now is the time to fill it up with useful configurations.

The build pipeline steps are:

• npm
• Gulp (or any other build process you are using)
• Archive files
• Publish Artifact

A quick info about the pipeline tasks

If you have not worked with Node.js before the npm (Node Package Manager) task will install the necessary packages that are required for our code to run. The specific package requirements are located in the package.json file.

The Gulp will compile out Typescript files into JavaScript files that we will eventually run

The Archive files task will bundle the files with the dependencies together.

Finally, Publish Artifact will publish our build result.

And now back to the task's configuration

If you have created the pipeline from a template (like in the example above), you will have to set the Agent Pool parameter depending on your needs.

Take a look at the official documentaiton for the exact capabilities and software version differences between the agents.

For the demo, I will choose the Hosted agent type.

In case you have created the pipeline from an empty template, configure your Agent job 1 to have the following Demands:

npm - exists  
node.js - exists  

The version that is configured on the agent does not mean that you cannot install a different version of Node.js just for your build process.
To do that you will need the Node Tool Installer task to the pipeline as the 1st step in the pipeline. All you need to do is to configure the Version Spec to the version that you are working with and you're set.

I am going to configure mine to install the latest 8.x version.

In our case, the Gulp task that starts the compile process is called build, so this is the task name that should be used in the Gulp pipeline tasks.

Once the Gulp task has finished, the compiled files are stored in the same location as your source.

Inside the Archive files task, change the Root folder field to $(System.DefaultWorkingDirectory)

The Archive files task will zip all of your and will create the archive file at the destination location.

The Publish Artifact task does not require any changes as the files it is publishing is from the $(Build.ArtifactStagingDirectory) directory.

After that simply click the Save and Queue button and wait for the build to finish.

Configuring the Release Pipeline

To deploy our newly created build we need to create a Release Pipeline.

When trying to create a new release pipeline we are greeted with the same selection, use a template or go with an Empty job.

As of writing these line, I strongly suggest using an empty job since it looks like the Deploy a Node.js app template has some unexplained issues.

We will not explore all of the options, for example, triggering a release once a certain set of conditions was met. Here we will just add a single task to the release stage.

After creating the pipeline from an empty job, we will need to add a single step Azure App Service Deploy

Here you will need to choose the subscription and the actual application that you want the task to deploy on.

A few small changes are needed here in order to run this successfully:

• Change the Package or folder field to $(SYSTEM.ARTIFACTSDIRECTORY)/**/*.zip

As of this writing, the latest stable version of the Azure App Service Deploy task is 3.* where the 4.* is still in preview.

A list of changes for the 2 versions can be found 3.x and 4.x

In case you are using 3.* under the File Transforms & Variable Substitution Options section check the Generate Web.config checkbox and add the following parameters

-Handler iisnode -NodeStartFile app/server.js -appType node

Note the NodeStartFile parameter pointing to the actual file that is going to be executed, in this case to the compiled .js file.

In case you are trying to use the 4.* version of the task, just add the values above to the Generate web.config parameters... input under the File Transforms & Variable Substitution Options section.

This will create a web.config file that is used by the IIS server that is running on the Web App, without it, your files will not be recognized.

Configure the Web App

Last but not least, the Web App itself.

I am assuming that you have already created a Web App for this, if not then a new web application can be created using the Azure Portal.

You need to make sure, that while creating this new Web App you set the publish method to Code

In case you are using Node.js version later than 0.10.* you will need to set the WEBSITE_NODE_DEFAULT_VERSION environment parameter in the Application settings of you Web App to your required Node.js version.

If you are into development of REST APIs, don't forget to check out RestCase - REST API Development, Supercharged! and perhaps register for a beta.

For questions/suggestions please comment below.

We often think of API definition as beginning with the description file, most of us are using swagger or OpenApi. The challenge with this approach is that API producers often get into the weeds on resource names and methods before actually determining what the API capabilities need to be.

When a company decides to release an API, depends on the API type, she must first accomplish an MVP (Minimal Viable Product). Then, this API must go through some feedbacks from the API consumers, in order to make sure the API provided is functional, reliable and usable.

Let's go over quickly over the types of APIs as most of the APIs can be divided into 3 groups - public, private and partner APIs.

Private APIs

This is the most closed format of providing and consuming APIs. Often private APIs are built to enhance process automation inside a company between systems. In other words, this is about integration economy inside one company.

Partner APIs

Partner APIs are revealed to other companies with whom we are ready to build a more tight connection. The other company might use some of our product data to expose our offering to their clients.

The company building REST API is providing other companies with a machine-readable API spec (swagger or OpenApi). Why? With that partner (candidate) could generate a mockup API mimicking your production API and develop integration against it. That would speed up integration and also reduce your work amount.

Public APIs

These APIs are listed in catalogs and not hidden from anyone. They are online and anyone can access those APIs (sometimes with authorization keys or another authentication mechanism) and the API definitions are public and visible to all.

Minimum Viable Product

Many organizations opt for the fast, easy win by releasing an “MVP” into the market with the intent to build on those concepts from there. While that may work for traditional products, it is far more challenging with APIs because of their role in applications that depend on them.

If you are going to provide an API that is both desirable and stable, you need to ensure that your initial API release is functional, reliable, and usable. A death knell for APIs is releasing constant breaking changes or updates that require the app developer to rework their app.

Nowadays, most of the companies have embraced the LEAN and the Agile methodologies, especially the working in sprints and doing a demo for clients each sprint. By doing this, the company allows refining the required vs desired capabilities before diving into the details of how to implement those capabilities, this is not only saving money in the long run but making sure that the API / product has actual value.

The main goal of this is understanding the value to the customer and constantly readjusting based on feedback got from the API consumers.

Getting Feedback

Taking the time to test your APIs in the market before committing to code or a roadmap can be a big investment of time and money. But making that investment pays off in many ways. Let’s look at some of the benefits of this approach:

• Planning the capabilities first allows you to think strategically about your release plans and your potential partners. When you commit yourself first to the inner workings of the API, you become locked to the technology rather than the strategy.
• By gathering feedback on your roadmap and capabilities, you can be agile about changing both of those because you haven’t already committed to an API design and code.
• Your potential API consumers are into your API as they have provided direction and strategic thought to help form your API. You are building what they asked for and they know it.

If you ask for feedback on your API concepts, you need to be prepared to react to that feedback and make sure that your organization is able to react to changes in plans. In other words - You may have to sacrifice speed for quality.

Establishing Feedback

Depending on the complexity of your API and the urgency to release it, you can use any number of techniques to get feedback on your API.

Developer Focus Groups

Organize a developers group in order to get feedback first of all from those that are going to actually use your API on the development level and on the concept/idea of the API itself. The goal of this is to make sure the API is something that is needed and can be adopted by developers.

Here are some tips for organizing a developer focus group:

• To keep this conversational, the ideal size for this type of gathering is no more than 30 people.
• Make sure you include a variety of participants – enterprise devs, start-up devs, product managers, all from a variety of verticals.
• Be prepared to show your concepts and encourage honest feedback. Do not convince, do not justify; this is a listening exercise. Explore the feedback with questions, questions, and more questions.

Publicly Available Mock

Ideally, you follow the focus group sessions with what you believe will be your first version of the API, but in mock form. The goal of this API (mock) is to move from concept to reality by exposing the API interface along with some mock data in a playground setting.

This will let developers make calls to the API, encourage feedback on the interface design and payload construction.

Providing client SDK can benefit later on, but not recommended for the first stage as developers will not actually use your API as they want and will be stuck in the SDK and what he allows.

Some things to consider when you make API mock available:

• Your API design should be as clean as possible. You need to consider security and versioning from this point and forward.
• Publish your draft documentation along with the API provided. API documentation is not a separate deliverable – it is part of the part the API itself. Do not forget to give many examples of both good and bad calls.

Beta / Invite Only

Okay, so we have gotten feedback on the API from focus groups before writing a single line of code and we created a mocked API along with first-draft documentation. Now it’s time to hit production.

This is where you really need to evaluate your risk tolerance. If your API does not involve secure information or mission-critical capabilities, you can deploy to production and open it for general use.

It is advised to slowly roll out the API to General Availability stage, by providing the API to a limited audience.

This gives you yet another opportunity to gather feedback and make improvements before making it more widely available.

Here are some general guidelines for the Invite-Only phase that can help you ensure your API is solid and meets market needs:

• Identify up front the size of the developer community you want to provide access to and keep the guardrails up to make sure it stays within that range.
• Decide how you want to build that community – do you want to reach out to specific developers who were engaged in the earlier iterations? Or do you want to have a publicly available sign-up form that you use to select your initial community?
• Be prepared to make changes based on this first real-world trial. You may feel that you’ve already done enough iterations. But bear in mind that this is the first-time developers are trying to build meaningful production-ready apps using your API. They will find things they didn’t find before – Oauth issues, documentation inaccuracies, rate limitations, performance problems, etc.

Set a pre-defined time range for this phase. Being in beta is addictive.

Releasing an API

For this, I personally recommend creating release criteria for an API (same as a regular product):

• Zero high priority bugs
• Penetration testing was done and passed
• For all open bugs, documentation in release notes with workarounds
• All planned QA tests run, at least 90% pass
• Number of open defects decreasing for last three weeks.
• Feature x unit tested by developers, system tested by QA, verified with customers A, B in the Invite-Only stage, before release

Once you meet your release criteria, you are ready to release.

Good luck!

I have been a REST API developer for many years and helped many companies to create APIs. One of the areas that are key to building a successful API is the error handling/response. Some time ago I wrote about the "REST API Error Handling Best Practices" which became a very popular post. At that time I wish that I know now about rfc7807, the standard actually defines the interface of a correct and well-known error response.

Background

Each company and even sectors are trying to define their own error response philosophy. But the common structure that defines a "good error code" consists of three basic criteria in order to be truly helpful:

• An HTTP Status Code, so that the source and realm of the problem can be ascertained with ease. This code takes the form of a standardized status code in the HTTP Status Code scheme. By noting the status using this very specific standardization, you not only communicate the type of error, you communicate where that error has occurred (5xx means that it is a server issue, whereas 4xx means that the client did something wrong).
• An Internal Reference ID for documentation-specific notation of errors. In some cases, this can replace the HTTP Status Code, as long as the internal reference sheet includes the HTTP Status Code scheme or similar reference material.
• Human readable messages that summarize the context, cause, and general solution for the error at hand.

FHIR

If we take for example the healthcare FHIR standard, the error is defined there as an FHIR resource called operation outcome, here is an example of the error response:

{ "resourceType": "OperationOutcome", "id": "exception", "text": { "status": "additional", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n<p>SQL Link Communication Error (dbx = 34234)</p>\n</div>" }, "issue": [ { "severity": "error", "code": "exception", "details": { "text": "SQL Link Communication Error (dbx = 34234)" } } ] }

The concept is very good, the interface (https://www.hl7.org/fhir/operationoutcome.html) is very generic and can be used for many responses, even successful ones. However in order to use it, you need to know the FHIR standard from A-Z and for some, the healthcare concepts are "a bit" overkill.

Google

Some companies like Google is using the following error response for their APIs:
{ "error": { "errors": [ { "domain": "global", "reason": "invalidParameter", "message": "Invalid string value: 'asdf'. Allowed values: [mostpopular]", "locationType": "parameter", "location": "chart" } ], "code": 400, "message": "Invalid string value: 'asdf'. Allowed values: [mostpopular]" } }

https://developers.google.com/doubleclick-search/v2/standard-error-responses

I just think that the JSON structure is a bit strange - errors array inside an error object?

Facebook

For Facebook the error response is different as well:
{ "error": { "message": "Message describing the error", "type": "OAuthException", "code": 190, "error_subcode": 460, "error_user_title": "A title", "error_user_msg": "A message", "fbtrace_id": "EJplcsCHuLu" } }

Spotify

{ "error" : { "status" : 502, "message" : "Bad gateway." } }

There are other examples out there but I think that everyone will agree that most of the error code structures are different. How you reference links, what error code you generate, and how to display those codes is subject to change from company to company.

However, there has been headway to standardize these approaches; the IETF recently published RFC 7807, which outlines how to use a JSON object as a way to model problem details within HTTP response.

RFC 7807 To The Rescue

This document defines a "problem detail" as a way to carry machine-readable details of errors in an HTTP response to avoid the need to define new error response formats for HTTP APIs.

By providing more specific machine-readable messages with an error response, the API clients can react to errors more effectively and eventually it makes the API services much more reliable from the REST API testing perspective and the clients as well.

In general, the goal of error responses is to create a source of information to not only inform the user of a problem but of the solution to that problem as well. Simply stating a problem does nothing to fix it – and the same is true of API failures.

RFC 7807 provides a standard format for returning problem details from HTTP APIs. In particular, it specifies the following:

• Error responses MUST use standard HTTP status codes in the 400 or 500 range to detail the general category of error.
• Error responses will be of the Content-Type application/problem, appending a serialization format of either json or xml: application/problem+json, application/problem+xml.
• Error responses will have each of the following keys:
  • detail (string) - A human-readable description of the specific error.
  • type (string) - a URL to a document describing the error condition (optional, and "about:blank" is assumed if none is provided; should resolve to a human-readable document).
  • title (string) - A short, human-readable title for the general error type; the title should not change for given types.
  • status (number) - Conveying the HTTP status code; this is so that all information is in one place, but also to correct for changes in the status code due to the usage of proxy servers. The status member, if present, is only advisory as generators MUST use the same status code in the actual HTTP response to assure that generic HTTP software that does not understand this format still behaves correctly.
  • instance (string) - This optional key may be present, with a unique URI for the specific error; this will often point to an error log for that specific response.

{ "type": "https://example.net/validation-error", "title": "Your request parameters didn't validate.", "invalid-params": [ { "name": "age", "reason": "must be a positive integer" }, { "name": "color", "reason": "must be 'green', 'red' or 'blue'"} ] }

You may provide additional keys that give the consumer more information about the error, also the Problem Details is extensible if a way that new problem details can be defined.

New problem type definitions MUST document:

1. A type URI (typically, with the "http" or "https" scheme)
2. A title that appropriately describes it (think short)
3. The HTTP status code for it to be used with.

For example, if you are publishing an HTTP API to your online shopping cart, you might need to indicate that the user is out of credit (our example from above), and therefore cannot make the purchase.

If you already have an application-specific format that can accommodate this information, it's probably best to do that. However, if you don't, you might consider using one of the problem details formats - JSON if your API is JSON-based, or XML if it uses that format.

To do so, you might look for an already-defined type URI that suits your purposes. If one is available, you can reuse that URI.

If one isn't available, you could mint and document a new type URI (which ought to be under your control and stable over time), an appropriate title and the HTTP status code that it will be used with, along with what it means and how it should be handled.

Example:

{ "type": "https://example.com/problems/request-parameters-missing", "title": "required parameters are missing", "detail": "The parameters: limit, date were not provided", "limit_parameter_format": "number", "date_parameter_format": "YYYY-mm-ddThh:mm-ss" }

In summary: an instance URI will always identify a specific occurrence of a problem. On the other hand, type URIs can be reused if an appropriate description of a problem type is already available someplace else, or they can be created for new problem types.

Implementations

Java : https://github.com/zalando/problem-spring-web

Node.js : https://www.npmjs.com/package/problem-json

Conclusion

I think that using it should be more and more common to use the proposed RFC-7807 - Problem Details specification, especially for its flexibility and simplicity. You can have your own custom error types, so long as you have a description of them to link to. You can provide as little or as much detail as you want, and even decide what information to expose based on environment (e.g., production vs development).

The advantages of using this can be a unification of the interfaces, making the APIs easier to build, test and maintain. Also I think that more advantages will come in the future when more and more API providers will adjust to this standard. I believe that client and server libraries will spawn and find many usages and even AI that deals with common error resolution is not farfetched.

RFC-7807 - Problem Details for HTTP APIs

REST is an acronym for Representational State Transfer. This is a software architectural style that allows for many protocols and underlying characteristics the government of client and server behavior.

Application Programming Interface (API) is a set of clearly defined methods of communication between various software components. A good API makes it easier to develop a computer program by providing all the building blocks.

Does Security Matter?

Security aspects should be a serious consideration when designing, testing and deploying a RESTful API.

In today’s connected world — where information is being shared via APIs to external stakeholders and within internal teams — security is a top concern and the single biggest challenge organizations want to see solved in the years ahead.

According to research by SmartBear presented in their State of APIs Report 2016:

• Security is the #1 technology challenge teams want to see solved; 41.2% of respondents say security is the biggest API technology challenge they hope to see solved.
• Security is the #4 technology area expected to drive the most API growth in the next two years; 24% of API providers say digital security will drive the most API growth in the next two years.
• 40.4% of API providers are currently utilizing a tool for testing API security

With the explosive growth of RESTful APIs, the security layer is often the one that is most overlooked in the architectural design of the API.

Some of the guidelines that should be considered in the security aspects when testing and developing REST APIs I will try to explain below.

Authorization

It is also important to have whitelist permissible methods. Sensitive resource collections and privileged actions should be protected. The API key or session token should be sent as a body parameter or cookie to make sure that privileged actions or collections are efficiently protected from unauthorized use.

You should ensure that the HTTP method is valid for the API key/session token and linked collection of resources, record, and action.

Clear access rights must be defined especially for methods like DELETE (deletes a resource) and PUT (updates a resource). Those methods must be accessed only by authenticated users only and for each such call, an audit must be saved.

Care should also be taken against cross-site request forgery. Here, one should be familiar with the prevention of XSS.

Authentication

It is important to be in a position to verify the authenticity of any calls made to one’s API. The ideal way would be to have a shared secret with all authorized users.

The simplest form of authentication is the username and password credentials one. Other types would include multi-factor authentication and token-based authentication.

Authentication goes hand in hand with authorization.

Auditing

Once in a while, security related events could take place in an organization. It is imperative that thorough auditing is conducted on the system.

This would involve writing audit logs both before and after the said event.

Token validation errors should also be logged in so as to ensure that attacks are detected. Log data should be sanitized beforehand for purposes of taking care of log injection attacks.

Input Validation

Automated tools have the capability to distort one’s interfaces when on high velocity. It is very important to assist the user, in line with the “problem exists between the chair” (PEBKAC) scenario.

Web services should require the input of high-quality data (validated data) or that that makes sense. If that is not the case, the input should be rejected.

Further options would include input sanitization and in some cases, SQL or XSS injection. The application’s output encoding should be very strong.

Other measures that would be taken include URL validations, the validation of incoming content types, the validation of response types, JSON and XML input validation should also be enforced when possible on the fields level. If for example, we know that the JSON includes a name, perhaps we can validate that it does not contain any special characters.

One more aspect is trying to follow URI design rules, to be consistent throughout your entire REST API.

TLS

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communications security over a computer network.

When secured by TLS, connections between a client and a server have one or more of the following properties:

• The connection is private (or secure) because symmetric cryptography is used to encrypt the data transmitted.
• The keys for this symmetric encryption are generated uniquely for each connection and are based on a shared secret negotiated at the start of the session.
• The connection ensures integrity because each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission.

TLS is quite heavy and in terms of performance, it is not the best solution. However, when used along with http/2, it will compensate for the speed and performance. You can read more about it here - http/2 benefits for REST APIs.

Cryptography

When it comes to security, this is probably the most important of the guidelines when building a REST API. REST APIs mostly handle data, coming to them and from them. It is also a very important doing security testing for your REST APIs.

In order to secure the DATA, you have to consider the following:

• Data in transit - The encryption of data transmitted to your API, this is mostly done on the infrastructure level like TLS and SSL support.
• Data in storage - The data you store, especially sensitive data must be encrypted or have restricted access (DB access, File Storage and etc..)
• Message integrity - The integrity of the data transmitted from your API to storage or to the client should be kept. Except for TLS, you can also calculate checksums (when it comes to files or objects that are uploaded in parts) or hashes of certain data in order to verify that no one handled the data while it was transmitted.

Here you always need to consider whether the API you are creating is internal or external API.

DOS Attacks

In a Denial of Service (DOS) attack, the attacker usually sends excessive messages asking the network or server to authenticate requests that have invalid return addresses. DOS attacks can render a RESTful API into a non-functional state if the right security measures are not taken.

Today, even if your API is not exposed to the public, it still might be accessible by others. This means that REST API security is getting more and more valuable and important.

Consider that someone succeeds in making a DOS attack, it means that all the connected clients (Partners, Apps, Mobile Devices and more...) will not be able to access your API.

RestCase -REST API Development, Supercharged!

Want an invitation to private beta?

Anti-Farming

There are always several marketing-heavy websites that offer consumers the best deal on everything from flights to vehicles and even groceries.

In many of these cases, the aggregated service is taking advantage of other APIs to obtain the information they want you to utilize. When this happens, the RESTful API is being farmed out for the benefit of another entity.

In case your API does not have an Authorization / Authentication mechanism, it might lead to miss-use of your API, loading the servers and the API itself making it less responsive to others.

HTTP Status Codes

It is important to consider numerous REST API status return codes, and not just using 404 for errors and 200 for success.

I wrote about those codes already but I think it is worth to mention again that other codes should be considered:

• 400 bad request - for the case when the validation did not pass.
• 401 unauthorized - When authorization of the user has failed, like
• incorrect username or password.
• 403 forbidden - This status is mostly for Authentication and Data Access Rights. It should indicate the user, that he does not have access to a specific resource in the API.
• 405 method not allowed - In case you do not support a method (like PATCH or DELETE for example)
• 429 too many requests - Can be used to signal that too many requests came from the same origin.

Summary

The above are some of the most important RESTful API security guidelines and issues and how to go about them. By at least trying to work with these guidelines, you will experience a more quality and secure REST API services and it will give you many benefits in the future.

For more about REST API security guidelines you can see checkout the following articles:

• Top 5 REST API Security Guidelines
• RESTful API Authentication Basics
• 5 Basic REST API Design Guidelines