Web Service Security: The Security Guide to Protect Your Web Service

In a time when technology is on the rise, concerns for web service security mirror its movement.

With the responsibility of carrying so much personal information about our customers, comes the task of managing the currency of data itself in an effective way. This is called web service security.

Part of hosting a web service is knowing the basics of web service security in order to protect your web application or website. Stay tuned to learn more about it!

What Is Web Service Security?

Web service security, also known as cybersecurity entails the methodologies involved in protecting a website or web application.

These methodologies specifically include detecting, preventing, and responding to cyber threats.

Data protection is crucial to web service security and there is no better way to illustrate this than the Equifax data breach, which impacted the personal information of approximately 147 million people in September of 2017.

Equifax is one of the three largest consumer credit reporting agencies in the US. It suffered a huge data breach all because of a little issue that could have been easily fixed.

More on that in a bit. In the wake of their scandal, Equifax will have to pay up to $700 million in fines as part of a settlement with federal authorities over this data breach.

There are many elements to web service security, but knowing the most fundamental parts might help you avoid a future breach and/or more than half a billion in fines.

Service-oriented architecture (SOA) security is a security model that addresses complex combination services as opposed to only one software program or platform.

Some standards implemented by SOA are explained below.

Authentication

Authentication refers to a means of verification for the user.

Using credentials, a password, or biometrics, or a combo of these methods, a service can verify that the user is who they claim to be.

Authorization

As a form of access control, authorization, grants users certain entitlements.

An employee in your tech company, for example, might have access to some directories and programming but not to the same degree as a higher level employee.

Related reading:  Work From Home Cybersecurity: 10 Steps to Avoid Risks

Confidentiality

Confidentiality, or privacy, is the practice of securing data from others.

Personal contact information, for one, should not be shared with those who can compromise the information.

Integrity

Integrity has to do with preventing the alteration of a message. Generally, a sender’s digital signature can certify its validity on one end.

This is closely related to non repudiation which ensures that the author of a statement cannot deny its authenticity.

These components of web service security are considered industry standard.

At this point, their implementation is so prevalent as to be considered enforceable web service security requirements.

Any company managing a web service should be aware of these standards and deploy them accordingly.

Why Do We Need To Protect Our Web Services?

Failing to secure web services can result in serious consequences for the user as well as the service itself.

As an illustration, one coding hosting service was victim to a breach in which an attacker gained unauthorized access to their Amazon Web Services account.

The result of this failure was more than just a fine. The company, called Code Spaces, had to close shop permanently.

The costs associated with such a web service security blunder as well as Coding Spaces’s initial disregard for creating an effective recovery plan proved to be at the root of its detriment.

The hacker had already deleted valuable data and content. This is just one instance of how web security, or a lack thereof, affected dire circumstances on a company’s success.

All small businesses face the same risk.

This, of course, does not even begin to scratch the surface of the customers whose information was put in jeopardy in the process.

Successful businesses are built on good reputations and healthy consumer relationships. Ineffective web service security will not garner that effect.

8 Ways to Secure Your Web Service

The idea that web service security is a necessary precaution has been well-established.

Now, if you’re wondering how to secure your web services, pay attention to the 8 strategic ways listed below, to put cybersecurity at the forefront of your business goals.

1. Don’t Trust Your Client 

There is no way of knowing whether our users have good intentions or not.

For vigilant web service security protocol, we should not trust any data inputted by our customer. This means that we need to check every input. We can do it with a blacklist or a whitelist.

In a blacklist, we have bad inputs that are deemed unacceptable as user inputs. In a whitelist, we have inputs that we allow to exist. Let’s take a look at an example.

We know that eval() is a function that executes strings as commands in Javascript.

Surely, a user with good intentions wouldn’t use this kind of content as an email. So, we will replace every eval() to be empty.

This can be helpful, however with every new threat we have to check our code and clean it up.

So for this stage, whitelists are more reliable than blacklists. We have awesome libraries that help us to create quick whitelists checks in our routes, for example, Hapi/JOI.

Look at this example, where we check the inputs for user authentication:

The example above is awesome because this library will guarantee us two things:

1. A good whitelist with good standards. If the input doesn’t fit with our standards, the new Error() will be triggered.
2. Protection against Parameter Injection, which means that the hacker tries to send more parameters to our routes. If there exists any different parameter besides email and password, the new Error() will be triggered;

In our example, the only parameters allowed are email and password, and they must adhere to our standards.

Don’t forget to use whitelists, they’re very helpful for web service security! They can help against Parameter Injection and XSS.

2. Use Bind-Params in Your SQL Statements

You’ve probably heard about SQL Injections, and how powerful they can be. If you haven’t heard about them then I suggest you read about them.

In addition, check OWASP Top Ten Attacks. But essentially, an attacker tries to change the queries that the system makes and gets access to the entire database.

I will never forget the day I was talking about SQL Injection breaches with one of my co-workers.

He challenged me to access a system that he made for his friend through a SQL Injection attack.

This system didn’t use the bind params, so I got the admin user and I put into the password field a well-known SQL Injection command to bypass the password for any user, and voilá! I got admin access.

Now, thinking back to this story, I feel that I should have bet on a beer with him.

The most simple solution is to use bind params. Bind params change the values inside of the database making it impossible to break the query and change to another one.

Nowadays, most ORMs use bind params as default but deliberately do not make a custom query and execute it without bind params.

For example, in Node.JS + Sequelize, if we want to use a custom query, we could do something like:

The image above shows two methods. The first method is an example with a custom query without bind params and the second is one with a custom query using bind params.

You might’ve guessed right – the second method is the better one.

If you have to use custom queries, then please, don’t forget to use the bind params. Also, ensure that your ORM uses them too.

I know Sequelize does this by watching the logs, and I know the most famous ORMs are using them.

But if you’re the kind of person that loves to try new technologies and libraries, this is a good point to start wondering whether that ORM is good or not.

Therefore, don’t use any kind of query without bind params. SQL Injection is considered one of the most famous of the top ten attacks on web applications, and it was discovered in the ’90s.

It shows how negligent the most developers and engineers have been.

I still don’t know why we don’t teach developers to use bind params since the first class to connect on the database and make queries.

3. Don’t Expose Sensitive Data

How often does your web service handle sensitive data?

If you never asked yourself this question, your web service likely exposes more sensitive data than you think.

The first step is to apply an SSL/TLS certificate on our web service and use it as the default connection. We can’t accept HTTP connections anymore for systems that use our personal information!

This certificate ensures that we have an encrypted connection between servers and customers, which almost mitigates “data sniffing” from a third party. This prevents a man-in-the-middle attack.

Next, ask yourself: How are you helping hackers access your information?

By showing system errors to them!

Errors can sometimes display a lot of sensitive information, such as the database system, table names, field names, constraint names, programming languages, and more.

Sometimes we can even see hosting information and passwords. When that happens, it gives hackers a means of exploring the known security breaches for the technology, systems, frameworks, and programming languages that your web service works with.

I can’t stress this one point enough. Do not show errors to users.

We need to intercept them and send them to programs like Rollbar or Sentry. These programs have great support for many languages.

Not to mention it’s pretty simple to configure your exceptions to show a default message to the user and send the system error to those tracker programs.

Altogether, it’s best to show the user a default error message or a descriptive user-friendly error message instead of showing the whole system error.

A great example of a default error message is “Internal Server Error”. It’s much safer for a system to show this rather than the whole system error.

4. Check Your Third-Party Libraries

I mentioned before that Equifax will pay up to $700 million in fines. Could you imagine your company being responsible for a huge data breach like that?

So, what happened with Equifax? Well, it’s not a complicated story to tell.

Equifax had a system that used Apache Struts. Two months before the attack, Apache Struts had announced a new patch to fix a specific vulnerability.

Two months later, the hacker was exploiting this vulnerability, meaning that Equifax didn’t update their systems.

This was the result:

• https://www.youtube.com/watch?v=e6fIuRqu6wc
• https://www.youtube.com/watch?v=V38eMXbK7gg

To prevent this kind of problem, we have to look at our third-party libraries. Nowadays, it’s almost impossible to create any application without using any third-party library or framework.

But one has to ask, who made that library? How well managed is it?

We are human beings and we make mistakes. Therefore, as a developer, it is your responsibility to manage the integrations you use.

This means assess their risks, understand the potential effects it can have on your system, and stay up to date on any updates.

There’s a fantastic tool called Snyk, which keeps developers alert to failures, vulnerabilities, and problems with your integrations.

Snyk has a huge database with a lot of contributors and when they find a new vulnerability, they warn all their customers that use Snyk in their applications.

Most of the time they fix the new vulnerabilities automatically with one command that you need to run. Also, Snyk warns you via your email.

Snyk is a truly incredible tool when it comes to web service security!

I personally love how companies are working hard to give consumers outstanding value, especially when it comes to security.

That’s why their valuation surpasses one billion dollars.

They also have free plans and priced plans. Currently, I use the free plan for my personal projects. They support many languages and package managers.

5. Set Limits for the User

I’m very enthusiastic about cryptocurrencies and Bitcoin, and I talk more about the usage of blockchain on Trio's blog.

I remember witnessing the exchange falling because Bitcoin’s price was rising too fast.

After the owner lost a lot of money, they decided to invest more in architecture and introduced a new feature to their APIs: limits to the client.

In the exchange, to guarantee good performance, they send a new result every minute. If you request the same route several times in that same minute, you’ll get the same cached result.

It’s a great way to ensure more performance and to decrease the chances of your server falling down.

Of course, we have to study and analyze the business impacts of caching the response every minute.

Using a layer to protect your service from DDoS attacks such as Cloudflare is also a great idea, and we can combine their solution with a good architecture on our APIs.

This is actually what the exchange did. They combined a cached result with Cloudflare DDoS protection.

6. Read the Security Section in the Manual of Your Library

Apparently, we are reading less and less, generation after generation. Also, we’re having problems paying attention for extended periods of time.

As a software engineer, I know that patience, attention, and reading are big facets of our daily routine.

Ergo, it’s vital that we discipline ourselves and read the documentation from our frameworks and third libraries, including the security section.

By using Express, I’ve noticed that we have a section called “Advanced Topics” and “Security Best Practices”.

This is awesome.

But I know that most software engineers that have installed Express haven’t read the Express documentation and probably never bothered diving into the “Advanced Topics” section, much less the “Security Best Practices” page.

Reading is probably the easiest way to familiarize yourself with the base tenets of web service security.

To my surprise, when I decided to implement Express in one of my APIs, I saw this section and found that Express offers wonderful documentation on how to protect your web service with Express.

With that documentation, I was able to learn how to use Express in a way that did not compromise my system in the future.

7. Don’t Be Paranoid and Continue to Study Security

After studying security for my applications and web services, I started to go a little crazy!

I couldn’t finish my tasks on time because I was thinking too much about all of the potential security breaches in my code.

We have to remember that even big organizations like the CIA, Sony, eBay, Yahoo, JP Morgan Chase, Netshoes, Dropbox, and YouTube, have been hacked.

Considering that, don’t be so paranoid about your services. After all, if the hackers really want to hack your application, they probably will find a way.

It’s just in their nature. The real question is: how much time do you need to identify that a hacker bypassed your security barriers?

With good logs and strong alerts strategy, we can identify breaches sooner and thus act on them quicker.

This is not an excuse to tell yourself that it’s pointless because hackers will win.

Developers and cybersecurity professionals work to build as many walls, mazes, traps and other defenses for hackers to become discouraged and leave their system alone.

So it’s best to make the hacker’s job as difficult as possible in hope that they will move on to their next target.

Also, don’t neglect to study web service security. This article covers the most basic webs service security techniques.

However, we should be learning these approaches in college or in beginner tutorials on the Internet. Most developers are not interested in protecting their services at a basic level.

That’s a problem.

Again, don’t be consumed with paranoia. At the same time, continue to study and invest time in protecting your applications.

A good resource to study is the OWASP page, especially the projects page. You can download the “Lab” projects and attempt to hack the software yourself.

These projects have security breaches implemented on purpose. It’s fun to learn in this way where you’re in the position of the hacker and the software engineer is trying to stop your attack.

This form of web services security testing is similar to a coding challenge. The Node.JS project OWASP learning environment is called NodeGoat. There’s a tutorial guide to help you hack and protect the project.

There are projects in other programming languages as well. It’s worth taking a look at them.

The only way to truly find ways to stop a hacker is to think like one and break your own system. This is the fundamental idea of penetration testing, which is a major player in web service security.

8. Logs and Monitoring

There are some situations where we need to audit our data to answer questions like “Who edited this line?” or “What’s making our server so slow?

These are key questions to ask in regards to web service security.

We can’t answer these questions if we don’t have good logs. That could be dangerous to any company, including if a company needs to identify a user with bad intentions.

Imagine the following situation:

Someone hacked your web service to process payments from the clients. And your boss asks, “How did the hacker pass through our security barriers?”

This could be a tough question if you don’t have good logs to start your investigation with.

I doubt any executive is trying to hear that there weren’t any logs and therefore there is no way of knowing.

That wouldn’t get you very far. Remember to make logs and make sure you have a system in place to keep track of them.

These are only a few of the strategies you can use to ensure that your web service is secure.

Like mentioned, you should take the time to do your own research and study up on best practices for web service security.

Conclusion

It’s important to start thinking about cybersecurity with our web applications and applying what we learn through research and practice to guarantee a safer system.

Equifax and Code Spaces are good examples of what not to do.

You can use the intel provided here to avoid those mistakes. This includes utilizing better coding techniques like bind-params or even making use of third-party services like Snyk.

If you want to guarantee your system is secure, it would be in your best interest to hire skilled developers to enhance your cybersecurity measure.

At Trio we offer remote software developers that can work cohesively with your company and business goals.

Hopefully, we’ve convinced you that web service security is one of them.

Contact Trio now to get the security you need.