Posts Tagged ‘API Implementation’

API Security: A Closer Look

Recently, we published a blog article discussing the growth of the “API Economy”: a term coined to describe the proliferation of API-based tools being incorporated into many software products and applications. In this article, we discuss one of the side effects of this growth: the need for more data security as a result of the growth of API use.

Application programming interfaces, or APIs for short, have transformed the way we create and use software by linking your application to other people’s code and data. Our APIs, for example, can be integrated into your code, CRM or e-commerce platforms to do things like validate your contact data against most of the world’s addresses, provide sales tax data down to specific address levels, verify and correct lead information, to name a few – right in your app.

APIs have truly opened up the world for applications such as retail, sales and marketing automation and much more. However, APIs have the potential to introduce security risks, particularly if they represent a pipeline to your data assets. A recent example of an API breach involved Australia’s largest property valuation firm exposing the loan details for over 100,000 customers.

The security risks of APIs are generally well understood by the developer community and our internal team pays close attention to changes and developments in this space. Below are some of the main thoughts on API security and risk management.

Security and APIs – What the experts say:

In 2016 David Berlind, the editor-in-chief of ProgrammableWeb, a portal site and directory for API developers, gave testimony to a government healthcare IT task force on current issues in API security. Here are some of the key points he raised:

Security starts with access to APIs. One of the largest concerns with APIs nowadays involves who gets the keys to the candy store – particularly if an API facilitates access to sensitive data. Berlind describes this in terms of APIs targeted at “LSUDs” (large sets of unknown developers) versus “SSKDs” (small sets of known developers). Increasingly, many firms are restricting access to their APIs and documentation to known and verified partners.

Security standards are still a work in progress. While specific API providers maintain their own security standards – for example, PayPal requires API users who store credit card data to follow PCI compliance rules – Berlind also notes that even major players such as Google, Apple and Facebook have all fallen prey to API breaches, and security standards are continually evolving.

Contractual protections matter. While this won’t stop bad actors, putting language in an API’s terms of service (TOS) can be an important tool for enforcing the proper use of APIs among customers.

Third party certification is needed. Given that API security continues to evolve, in what Berlind calls a “cat and mouse” game between hackers and developers, he feels that there will ultimately need to be an industry-wide API security standard that is continually informed by what we learn from the latest security incidents.

Since this testimony, dialogue continues around the evolution API security, including this list of best practices such as front-end authorization and authentication, checking results data, and investing in proactive security testing. Much more remains to be done in this area, but at least this topic is at the forefront of the API developer community.

Our perspective on API security

Of course, we are API developers ourselves, so we are extremely sensitive to the issues of API security. Part of this springs from self-interest: for vendors like us, who handle sensitive personal data for what are often mission-critical applications, our business depends on it. But we are also observing the growth of the entire API ecosystem with interest, and this is a topic we all need to be talking about.

Our API products carry less risk because we do not store customer data. Instead, each record a customer submits to us is processed through a secure and encrypted connection, generally by validating it against one or more databases, and validation results are returned through a secure and encrypted connection. We neither store customer input nor resulting output, so there is little to “steal” by calling our APIs.

Personally, we feel that part of the solution is for API developers to adopt accepted best practices in data security, and document these procedures publicly – ours are here, for example. To create more customer confidence as APIs proliferate, our industry will increasingly need to take people inside the “black box” of API infrastructure and discuss what steps are being taken to protect their data. We are glad to be part of this dialogue, and will continue to be part of it in the future.

Tuning your Implementation: What Impacts Speed and Throughput

How fast is fast? How fast should things be? And more importantly, what can you control to make the response time of using our services as fast as possible?

In this blog we will break down the key components of response time, to shed some light on what you can optimize to make your implementation respond faster. Whether it is a call to a Service Objects web service or an API integration in general, there are specific phases that take place: input data preparation and transmission, data processing, and results transmission and processing. For example, a simplified view of a single data validation request is as follows:

  • Your data is securely sent to the Service Objects web server to be processed
  • The data is received by our server and processed/validated
  • The validated data is then securely returned to you

Most people think of response time as being the round-trip time to get your data validated – and this is indeed the primary concern – but total throughput should be addressed as well. And if you are able to get a single validation done as optimally as possible, expanding the workflow to fit simultaneous requests shouldn’t take too much modification to the workflow.

To understand what is going on under the hood – and in particular, understand what factors may be slowing down your speed – let’s compare this process to a trip to the grocery store. It has similar phases to a data validation process: you leave your house, travel down the road, stop at the market, purchase your groceries, and then drive home. Here is how this process breaks down:

Step 1: Data preparation. This is analogous to the steps you take before leaving your home. Did you turn off the lights? Are all of the doors shut? Is the security system armed? Do you have everything on your grocery list?

Each of these steps is similar to the checks that your application goes through in order to leave your company’s internal network. The application has to gather the information to be processed, dot all of the i’s, cross all the t’s, make sure it knows where it is going, and make it through any layers of security your company has in place. Each layer takes time to complete and detracts from your overall speed.

Step 2. Input data transmission. This is like traveling down the road to the supermarket. How much traffic people encounter depends on factors such as how many lanes the road has, how many people are in each car, and how many cars are on the road. From an engineer’s perspective, this is like the concept of single threading and multithreading: if the road that you are traveling down has multiple lanes, the number of cars (e.g. API requests) can be larger before running into traffic.

By creating a multithreaded application, you can effectively widen the road and allow for more throughputs. Your choices include single car + single lane (single value request), single car with multiple people in it + single lane (smartly using one validation client to do multiple requests), multiple cars with single passengers on multiple lanes (semi-smart multithreaded validations), and multiple cars with multiple passengers on multiple lanes (really smart multithreaded apps).

Step 3. Data processing. Once you reach the store and make your purchases, it is time to pick a checkout aisle. The number of aisles that are open act similarly to the lanes on the road. More aisles allow a larger number of people to be processed before a queue builds up.

This part of the process is handed by Service Objects. We have spent the last 15+ years not only making sure to stock our shelves with the best quality products, but also ensuring that there are enough checkout aisles to meet the needs of our customers. In our case, we have multiple data centers (super markets) with load balanced web servers (smartly managed checkout aisles) to keep all of our transactions moving through smoothly.

Step 4. Results data transmission. The return trip from the super market is very much the same as the trip there, but in reverse order. Similarly, entering your house with the newly purchased items (validated data) is the same in the opposite direction. This stage also contributes to the round trip time required to process a request.

Step 5. Unpacking the results. When you return from the store, you still have to unpack your groceries. Likewise, once you get the data back from the service, you still need code and business logic to unpack the results and store them in a form that meets your needs. (Or, to extend our analogy further, create a delicious meal from the quality ingredients that Service Objects supplies you!)

So total processing time is a careful balance of getting through your front door, navigating down the single or multi lane highway, checking out with your groceries, and then making the return trip home. From an API-call perspective, improvements to your speed start with your network, smart choices when writing your integration code, and juggling the requirements put in place by your business logic. And if you are looking to increase your throughput, a multithreaded application or distributed system will often increase your capacity.

Finally, one more analogy (we promise!). Good grocery stores have staff who can help you make the most of your shopping trip. Likewise, Service Objects has an industry-leading team of technical support experts who know their stuff, and are always happy to help you make the most of your implementation. How can we help you? Contact us any time to discuss your own specific needs.