When they’re building an application, developers have to consider how that application will connect to the data sources that will help it function. To date, the most common options have been to build and use an API that connects to the data sources, or to implement direct database access.
Most recently, developer teams tend to opt for the API option. This reflects the expanding use of APIs as a whole — 98% of developers consider APIs essential for their work — and also speaks to some of the benefits that APIs have over direct database access.
In this article, we’ll outline the differences between APIs and direct database access and highlight why teams are choosing to employ APIs more often than not.
Direct Database Access vs. APIs
Direct database access is a process through which applications connect directly with databases to request information. Whenever a user requests an action or piece of information from the app, the app then requests the information it needs from the database.
While this approach is relatively simple to execute (particularly if it’s an internal database or one that’s openly available), direct database access can pose a number of challenges.
These include:
- Security concerns that come with direct access to a large swathe of data.
- The challenges that come with connecting to multiple databases directly.
- The need to implement multiple database layers to make it function properly.
APIs, meanwhile, have become the building blocks of modern applications because they facilitate communication between applications and data sources. While they’re a more layered approach than direct database access, it makes it much easier to leverage data from third-party databases, and multiple ones at that.
The benefits of leveraging REST API connectivity to retrieve information from databases include:
- The ability to interact with several programming languages.
- The reusability of the front end. Existing APIs can be applied to other web apps, microservices, and mobile apps.
- Flexibility to work with multiple data formats.
- APIs tend to be set up with load balancing capabilities that reduce latency issues and prevent databases from processing too many queries at the same time.
- APIs are more scalable and can better process shifts in usage.
- They integrate easily with most business intelligence tools.
In addition to this, APIs — paired with a robust API security strategy — provide a more secure approach to obtaining information from databases.
The Security Problem of Direct Database Access
Today, businesses have more access to data than ever before, and that includes personal customer data. Bad actors are also increasingly interested in getting ahold of this data, and have become more sophisticated in their efforts to attain it. As a result, companies need to ensure their databases are secure and protected from breaches.
Unfortunately, while direct database access facilitates direct access to useful information without too much coding, it doesn’t have the same security protocols that an API can provide. This means it opens the door to a number of cybersecurity threats, including:
- DoS and DDoS attacks: These tend to happen when bad actors compromise database connectors and issue commands that confuse the database. The availability of direct database access connectors can create vulnerabilities in this regard.
- SQL injections: Direct database access connectors can be powerless against SQL attackers, especially if the right security protocols aren’t in place.
- Malware: Direct database access connectors can be used to inject malware into the database.
In other words, direct database access is difficult to secure and therefore increases the potential for gaps in a company’s security posture.
Security and APIs
It’s true, APIs are considered to be one of the most prominent attack vectors for businesses today. Like direct database access connectors, APIs are particularly appealing because they handle information and have access to the database and other parts of the business. In addition, APIs can be notoriously hard to secure because of the limited standards within the API landscape and the propensity for teams not to test business logic gaps within an API.
That said, many APIs have built-in security considerations. REST APIs, for instance, have:
- Authentication mechanisms including API keys, OAuth tokens, or JSON Web Tokens to verify the identity of clients.
- Authorization mechanisms to control who has access to what.
- Rate limiting that restricts the number of requests a client can make within a certain time frame.
- Input validation that helps prevent SQL injections and other attacks.
- HTTPS encryption to encrypt the data transmitted between the client and server. This prevents any unauthorized interceptions.
- Cross-origin resource sharing headers that control which domains can access the API.
In addition, with a comprehensive API security solution and strategy, APIs can vastly reduce the risk to the database. A modern API platform will support teams with testing, monitoring, identifying security gaps, classifying data, and setting a baseline for API behavior.
As developers continue to opt for APIs over direct database access connectors, they will need to build a culture of security around their API development process to ensure that security is a consideration from the get go. This way, they will be able to continue innovating and taking their product capabilities further without compromising their security posture.
Ali Cameron is a content marketer that specializes in the cybersecurity and B2B SaaS space. Besides writing for Tripwire's State of Security blog, she's also written for brands including Okta, Salesforce, and Microsoft. Taking an unusual route into the world of content, Ali started her career as a management consultant at PwC where she sparked her interest in making complex concepts easy to understand. She blends this interest with a passion for storytelling, a combination that's well suited for writing in the cybersecurity space.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.