- [Instructor] Just as with all
of our critical network components,
REST APIs have some best security practices
that we do need to be aware of.
There are multiple ways to accomplish this,
but the overarching theme of these authentication methods
is that they should all be stateless.
And by stateless authentication,
we mean that the authentication
and authorization credentials
should not be cached or stored in any way.
Each and every request made to the server
should require validation in some way.
We want to outline several well-known
general security design principals
for REST APIs here, starting with least privilege.
Least privilege means that users should be authorized
only for very specific actions.
They should only have enough permission
to accomplish what they need in order to do their job,
and no more than that.
Further, this means that if there's a change in their needs,
so if a user no longer needs authorization
for a specific action,
that permission should be revoked immediately.
We also have a principle called fail-safe defaults.
The default action should be to deny access
unless a user is explicitly given permission.
This is the same principle we see in the logic
of access control lists,
where everything is explicitly denied
unless permission is explicitly given.
The principle of mechanism economy means
that whatever security design that's in place
should be simple and intuitive.
The interactions between different systems and APIs
should be easy to understand,
especially to administrators.
The complete mediation principle
is what we outlined in the introduction,
meaning that cached permissions should not be allowed.
Each call or request should require its own validation.
Separation of privilege means that
giving access to a user should not be based
purely on a single condition.
An administrator shouldn't necessarily
have access to everything, in other words
but they should have access only to specific resources
that should require very specific authorization.
There should be an open design principle, as well,
where open source solutions are used.
You wouldn't want to use secret or confidential algorithms
but you would want to rely
on well-known protocols and standards.
Also, the security should be psychologically acceptable.
And that means that it should not be challenging
to access or to use.
There's no reason that strong security postures
should ever hinder the user experience
or the user interface.
And finally, something called least common mechanism.
We should shield REST APIs from opportunities
for multiple unwanted entities
to potentially access those.
Serving an application on the internet
when it's not necessary to do so
is an example of that.
That means that we're exposing that application
both to legitimate users and to potential attackers.
You can read more about these principles
in the excellent paper created by members
of the IEEE council by looking up
The Protection of Information
in Computer Systems document.
This is regarded as an authoritative resource
for REST API security design.
To sum up some of the best practices
for securing our REST APIs,
we can do that with four main suggestions.
First, always use HTTPS.
HTTPS leverage is SSL, which creates
a randomly generated access token
that is delivered each time.
This is relatively easy to configure and use,
and it's something you can do for free
that gives you a lot of great security features.
Using a hashed password
with REST API services is also critical.
With a strongly hashed password
using strong algorithms, such as the SHA-2 family,
even if your password is exposed to attackers,
they will not be able to interpret the data.
Input parameter validation should happen immediately.
In other words, when requests arrive,
and credential validation takes place,
you want to make sure this happens
before the request reaches any of the application logic.
So this should be configured to immediately reject
any request that fails validation,
keeping those problematic or potentially harmful requests
away from your application.
And the final best practice
is to consider using OAuth.
Rather than basic authentication,
which sends credentials along with the request,
OAuth will redirect users
to a third-party validation service.
This is especially important if you use web services.
An example of this is the way
that many websites will now allow you
to create accounts using your Facebook
or Google login account.
But rather than providing those credentials
directly to the website,
you're directed to Facebook
or you're directed to Google,
to log in through their platform
so your credentials aren't unnecessarily exposed
to third-party websites,
and you're still granted access.
So that's a look at REST API design principles
and best practices for REST API security.