API

• API stands for Application Programming Interface

• A type of software interface
• APIs are a way for one program/system to interact with another program/system
• API calls are the medium by which they interact. An API call, or API request, is a
message sent to a server asking an API to provide a service or information.
Open your smartphone or tablet and look at the apps you have installed.
Those apps are talking to one or more remote APIs to download fresh content
and messages, poll for notifications, upload your new content, and perform
actions on your behalf
Load your favorite web page with the developer tools open in your browser,
and you’ll likely see dozens of API calls happening in the background
• An API handles requests from clients on behalf of users
• Clients may be web browsers, mobile apps, devices in the Internet of
Things, or other APIs
• The API services requests according to its internal logic and then at
some point returns a response to the client
• The implementation of the API may require talking to other
“backend” APIs, provided by databases or processing systems.
API styles
• Remote Procedure Call (RPC)

• Remote Method Invocation (RMI)

• REpresentational State Transfer (REST)

API styles
• Remote Procedure Call (RPC) - APIs expose a set of procedures or
functions that can be called by clients over a network connection
• Resembles normal procedure calls as if the API were provided locally
• Uses binary formats for messages
• Very efficient
• Usually requires the client to install specific libraries (known as stubs) that
work with a single API
Eg. The gRPC framework from Google (https://grpc.io) is a modern RPC
approach
API styles
• Remote Method Invocation (RMI) - uses object oriented techniques
to allow clients to call methods on remote objects as if they were
local
• Technologies such as CORBA and Enterprise Java Beans (EJBs) were
often used for building large enterprise systems but the complexity of
these frameworks has led to a decline in their use.
API styles
• The REST (REpresentational State Transfer) API also communicate through
HTTP requests to perform standard database functions like creating,
reading, updating and deleting records (also known as CRUD)
For example, a REST API would use
A GET request to retrieve a record
A POST request to create a new record
A PUT request to update a record
A DELETE request to delete a record
• In contrast to RPC, RESTful APIs use standard message formats and a
small number of generic operations to reduce the coupling between a
client and a specific API. Use of hyperlinks to navigate the API reduce the
risk of clients breaking as the API evolves over time.
API styles – Which are used widely?
• A REST API is typically used in applications as it is easier for
developers to understand and implement. However, RPC still
exists and is used when it suits the use case better. Modern
implementations of RPC, such as gRPC, are now more popular.
API security
• The more APIs are used, the greater their potential to be attacked
• API Security lies at the intersection of three security areas,
Information security (InfoSec) is concerned with the protection of
information over its full life cycle from creation, storage, transmission,
backup, and eventual destruction
Network security deals with both the protection of data flowing over a
network and prevention of unauthorized access to the network itself
Application security (AppSec) ensures that software systems are
designed and built to withstand attacks and misuse.
• From information security we will learn how to:
Define your security goals and identify threats
Protect your APIs using access control techniques
 Secure information using applied cryptography

• From network security we will learn:

The basic infrastructure used to protect an API on the internet,
including fire walls, load-balancers, and reverse proxies, and roles they
play in protecting your API
 Use of secure communication protocols such as HTTPS to protect
data transmitted to or from your API
• Finally, from application security we will learn:
 Secure coding techniques
 Common software security vulnerabilities
 How to store and manage system and user credentials used to access
your APIs
Typical API deployment
Typical API deployment
• Requests to your API servers will typically pass through several other
services first
• A firewall works at the TCP/IP level and only allows traffic in or out of
the network that matches expected flows
• A load balancer routes requests to appropriate internal services based
on the request and on its knowledge of how much work each server is
currently doing
• A reverse proxy or API gateway can take care of expensive tasks on
behalf of the API server, such as terminating HTTPS connections or
validating authentication credentials.
Elements of API security – Factors to
consider for API security
• First, the same API may be accessible to users with distinct levels of
authority (administrators and users) which should not be. The API
may also be exposed to users on the internet who shouldn’t have any
access at all. And so, any user can perform any undesirable action
• Second, while each individual operation in an API may be secure on
its own, combinations of operations might not be. The security of an
API needs to be considered as a whole, and not as individual
operations.
Elements of API security - Factors to
consider for API security
• Last, there may be security vulnerabilities due to the flaws in the
implementation of the API. For example, failing to check the size of
inputs to your API may allow an attacker to bring down your server by
sending a very large input that consumes all available memory; a type
of denial of service (DoS) attack
Security goals
• Confidentiality—Ensuring information can only be read by its intended
audience
• Integrity—Preventing unauthorized creation, modification, or destruction
of information
• Availability—Ensuring that the legitimate users of an API can access it
when they need to and are not prevented from doing so
• Accountability - keeping track of user activity while users are logged in to
a network
how long they were logged in, the data they sent or received, their IP
address, the Uniform Resource Identifier (URI) they used, and the
different services they accessed
• Non-repudiation - not being able to deny having performed an action
Token-based authentication
HTTP basic authentication
• The Password is not encrypted or hashed
• Here, the web browser must submit the User ID and the Password to
the web server on every API call
• The web server must verify the User ID and the password on every
API call
Drawbacks of HTTP basic authentication
• The user’s password is sent on every API call, increasing the chance of it
accidentally being exposed by a bug in one of those operations
• Verifying a password is an expensive operation and performing this
validation on every API call adds a lot of overhead
• The dialog box presented by browsers for HTTP Basic authentication is
pretty ugly, with not much scope for customization. So, this affects the
user’s experience
• The browser will not forget the password even after closing the browser
window. On a public terminal, this is a serious security problem if the next
user can visit pages using your stored password just by clicking the Back
button.
Token-based authentication
• Token-based authentication is more secure than HTTP basic authentication
• Rather sending the username and password directly to each API endpoint,
the client instead sends them to a dedicated login endpoint
• The login endpoint verifies the username and the password and then
issues a time-limited token
• The client then sends the token on subsequent API requests to the other
API endpoints to authenticate the user
• The API endpoints can validate the token by looking it up in the token
database (database indexed by token id)
Storing the token at the client side
• One option to store the token at the client side is in the form of a cookie
• Cookies are a great choice for first-party but not when dealing with third-
party clients
Token store abstraction – UML class
diagram (TokenStore interface and the
Token class)
Token store abstraction
• Token class
Username
Expiry time
A collection of attributes - information like how the user was
authenticated or other details to make access control decisions.
• Two operations in the TokenStore interface:
 One is for creating a new token
 Another is for reading a token from the token store given its ID.
Implementing token-based login
• The user controller (UserController class) validates the user’s
credentials
• The user controller authenticates the user with HTTP Basic
authentication as before. If that succeeds, then the request continues
to the login endpoint (TokenController class), which can retrieve the
authenticated subject from the request attributes. Otherwise, the
request is rejected because the endpoint requires authentication.
Drawbacks of token-based authentication
• While token-based authentication is more secure than HTTP basic
authentication, it's not foolproof. It's possible for an attacker to get the token
and use it to access the data until the token expires
Session cookies
• The simplest implementation of token-based authentication is cookie-
based
• Here, after the user successfully logs in, the server sends a Set-Cookie
header on the response with a random session token
• On subsequent requests to the same server, the browser will send the
session token back in a Cookie header, which the server can then look
up in the token store to access the session state
• Spark is a Java based web framework which supports cookie-based
implementation
• The create method is invoked only if the login authentication is
successful
• var session = request.session(true)
• This will create a new session (and the session token), if there is no existing
session
• If the session already exists, then it will return the existing session and not
create a new one
Session Fixation attack
• Session fixation attack occurs when an API fails to generate a new session
token after a user has authenticated. Here, the attacker tricks the user into
using the attacker’s session token
 The attacker captures a session token from loading the site on his own
device and then injects that token into the victim’s browser. Once the
victim logs in, the attacker can use the original session token to access
the victim’s account.
Avoiding session fixation attack
• Session fixation attack can be prevented by invalidating any existing
session after a user has authenticated
First, you should check if the client has an existing session cookie by calling
request.session(false). This instructs Spark to return the existing session, if
one exists, but will return null if there is not an existing session.
Invalidate any existing session to ensure that the next call to
request.session(true) will create a new one.
Avoiding session fixation attack
Cookie security attributes
• Set-Cookie:
JSESSIONID=node0hwk7s0nq6wvppqh0wbs0cha91.node0;Path=/; Secure;

HttpOnly

Secure – The cookie can be sent only over https connections

HttpOnly – The cookie cannot be read by JavaScript, making them slightly
harder to steal through XSS attacks
SameSite – The cookie will only be sent on requests that originate from the
same origin as the cookie.
Cookie security attributes
Domain – If no Domain attribute is present, then a cookie will only be sent
on requests to the exact host that issued the Set-Cookie header. This is
known as a host-only cookie. If you set a Domain attribute, then the cookie
will be sent on requests to that domain and all sub-domains. For example,
a cookie with Domain=example.com will be sent on requests to
api.example.com and www.example.com.
Path - If the Path attribute is set to /users, then the cookie will be sent on
any request to a URL that matches /users or any sub-path such as
/users/mary, but not on a request to /cats/mrmistoffelees.
Expires and Max-Age - Sets the time at which the cookie expires and
should be forgotten by the client, either as an explicit date and time
(Expires) or as the number of seconds from now (Max-Age).
Persistent cookies
• Session cookies are temporary and are used to maintain information about
a user's activity during a single browsing session. Session cookies are
deleted when the browser window or tab is closed.
• Persistent cookies are permanently stored by the browser and can be
accessed across multiple browsing sessions.
Securing Natter APIs
• Natter—the social network for coffee mornings, book groups, and
other small gatherings.
• The Natter-API - social media API that allows the creation of spaces
and the publishing of messages. It keeps tracks of messages within a
space.
Operations supported by Natter API
• A HTTP POST request to the /spaces URI creates a new social space. The
user that performs this POST operation becomes the owner of the new
space. A unique identifier for the space is returned in the response
• Users can add messages to a social space by sending a POST request to
/spaces/<spaceId>/messages where <spaceId> is the unique identifier of
the space.
• The messages in a space can be queried using a GET request to /spaces/
<spaceId>/messages. A since=<timestamp> query parameter can be used
to limit the number of messages returned to a recent period
• Finally, the details of individual messages can be obtained using a GET
request to /spaces/<spaceId>/messages/<messageId>.
Addressing threats with Security Controls
• The Natter API can be protected against common threats by applying
some basic security mechanisms (also known as security controls).
Five basic security controls
• Encryption prevents information disclosure
• Rate-limiting protects availability
• Authentication is used to ensure that users are who they say they are
• Audit logging records who did what, to support accountability
• Access control is then applied to enforce integrity and confidentiality.
• Together these five basic security controls address the six basic STRIDE
threats of
Spoofing (Authentication can be done to prevent Spoofing)
Tampering
Repudiation
Information disclosure (Can be prevented by Encryption)
Denial of service (Can be prevented by Rate-limiting )
Elevation of privilege
Rate Limiting for Availability
• Rate limiting is a strategy for limiting network traffic
• It can be used to guard against DoS and DDoS attacks (which are attacks
against availability)
• A Denial of Service (DoS) attack aims to prevent legitimate users from
accessing your API
 This can include physical attacks, such as unplugging network cables,
but more often involves generating large amounts of traffic to
overwhelm your servers
• A distributed DoS (DDoS) attack uses many machines across the internet
to generate traffic, making it harder to block than a single bad client.
Application-layer DoS attacks
• Application-layer DoS attacks (also known as layer-7 or L7 DoS) send
syntactically valid requests to your API but try to overwhelm it by
sending a very large volume of requests.
DNS amplification attack
DNS Amplification Attack
• DNS query
Requests the IP address of a domain eg. Request the ip address of
google.com
• In a DNS amplification attack, the attacker sends the same DNS query to
many DNS servers, spoofing their IP address to look like the request came
from the victim. By carefully choosing the DNS query, the server can be
tricked into replying with much more data than was in the original query,
flooding the victim with traffic
• Rate-limiting can be done in the API server
• But it is better to do early in the reverse proxy or load balancer before the
request reaches the API server
• Rate-limiting rejects requests when your API is under too much load. By
rejecting requests early before they have consumed too many resources,
we can ensure that the requests we do process have enough resources to
complete without errors.
Rate-limiting with Guava
• Done in API server
• Using Google’s guava library
• Even if you enforce rate-limiting at a proxy server, it is good security
practice to also enforce rate limits in each server so that if the proxy server
misbehaves or is misconfigured, it is still difficult to bring down the
individual servers. This is an instance of the general security principle
known as defense in depth.
• The principle of defense in depth states that multiple layers of security
defenses should be used so that a failure in any one layer is not enough to
breach the security of the whole system
Rate-limiting with Guava -
Implementation
• Add the following dependency to the dependencies section in
pom.xml file
Rate-limiting with Guava -
Implementation
• Guava makes it very simple to implement rate-limiting using the
RateLimiter class that allows us to define the rate of requests per
second you want to allow.
• You can then either block and wait until the rate reduces, or you can
simply reject the request.
• The standard HTTP 429 Too Many Requests status code can be used
to indicate that rate-limiting has been applied and that the client
should try the request again later.
• You can also send a Retry-After header to indicate how many seconds
the client should wait before trying again.
Rejecting the requests if the rate limit is
exceeded
Authentication
• Authentication is done to prevent spoofing
HTTP Basic Access Authentication
HTTP Digest Access Authentication etc.
Encryption
Using encryption to keep data private
• Sending password in plain text is a big vulnerability, so let’s fix that by
enabling HTTPS
HTTPS is normal HTTP, but the connection occurs over Transport Layer
Security (TLS) which provides encryption and integrity protection.
Enabling HTTPS on a website
Enabling HTTPS on your website involves installing an SSL/TLS certificate
on the server and configuring the server to use it
• The SSL/TLS Certificate:
The server must present a certificate signed by a trusted Certificate
Authority (CA). If an invalid certificate is presented, or it doesn’t
match the host that the client wanted to connect to, then the client
will abort the connection.
Enabling HTTPS on a website
A self-signed certificate can be used on local host for development
purpose.
A self-signed certificate is created and signed by the entity (like a
website owner) that will be using it, rather than a trusted Certificate
Authority (CA)
mkcert tool is used to create the self-signed certificate
“mkcert –install” command creates the certificate
mkcert generates certificates in Privacy Enhanced Mail (PEM) format.
For Java, you need the certificate in PKCS#12 format, so run the
following command in the root folder of the Natter project to generate
a certificate for localhost
mkcert -pkcs12 localhost
Enabling HTTPS on a website
The certificate and the private key used to sign the certificate will be
generated in a file called localhost.p12. The default password for the
file is “changeit”
Enable HTTPS in Spark by adding a call to the secure() static method
Enabling HTTPS on a website
• The last two arguments to secure call is null; these are only needed if
you want to support client certificate authentication
• After adding the call, restart the server
Strict Transport Security (HSTS)
Configure your server to automatically redirect any website traffic
coming through HTTP to HTTPS. This ensures all communication is
encrypted.
Strict-Transport-Security (HSTS) is a web security feature that can be set to
enforce HTTPS connections for a website. It essentially tells compatible
web browsers to only interact with the site using secure HTTPS
connections
Webservers can activate HSTS by sending a special response header
(Strict-Transport-Security) to web browsers.
response.header("Strict-Transport-Security", "max-age=31536000");
Audit Logging
Audit Logging for Accountability
• Accountability holds users and peers on a network responsible for their
actions.
• The simplest way to do this is to keep a log of actions (who did what and
when) that people perform using your API, known as an audit log
• Audit logs should be in durable storage, such as the file system or a
database, so that the audit logs will survive even if the system crashes
• Audit logging should occur
After authentication (so that you know who did what)
SIEM (Security Information and Event
Management) system
• SIEM is a centralized log collection and analysis tool
• The audit logs can be sent to SIEM
• SIEM correlates the sent logs with the logs from other systems
inorder to analyze for potential threats and unusual behavior.
Who can access the audit logs?
• Since the audit log contain sensitive information, it must not be accessed
by all. The access to audit logs should be restricted. Principle of SoD must
apply here
• (The Principle of Separation of Duties (SoD), also known as segregation of
duties, is a security measure used in organizations to prevent errors and
malicious activities. It works by dividing tasks and responsibilities across
different individuals or teams.)
• Auditors are the users who can access the audit logs
• They are different from the normal system administrators
The Audit table
• The audit table stores the audit logs
• Here, each entry will have an identifier (used to correlate the request
and response logs), along with some details of the request and the
response
• For implementation, the logging is split into two filters:
One of which runs before each operation (before the request is
processed)
And one which runs afterward (after the response is produced)
• auditRequestStart method is called before processing the request
• auditRequestEnd method is called during processing the response
• To allow somebody reviewing the logs to correlate requests with
responses, generate a unique audit log ID in the auditRequestStart
method and add it as an attribute to the request.
• In the auditRequestEnd method, you can then retrieve the same
audit log ID so that the two log events (request and response) can be
tied together.
Securing service-to-service APIs
Service-to-service API
• One service can request data or functionality from another service
• APIs are used for the communication between the services
• Here, the service which is requesting data/functionality is the service client
and the other service is the service provider
• The service provider must authenticate the service client before providing
the data/functionality
• Forms of service authentication
API Key (most common)
OAuth2
Securing service-to-service APIs - API
keys
API keys
• An API key is a token that identifies a service client rather than a user. An
API key usually has a longer expiry time - valid for a much longer time
than a user token, often months or years.
API Keys
API Keys
• The API key is generated by a developer portal
A representative of the organization logs into a developer portal and
requests an API key. The portal generates the API key and returns it.
The developer then includes the API key as a query parameter on
requests to the API.
API keys
• Advantage
API keys are relatively easy to understand and implement. They are
often just a long string of characters
• Disadvantage
Not secure: If compromised (e.g., leaked or stolen), anyone with the
key can impersonate the authorized application and potentially misuse
the API
Limited Authorization: API keys typically provide basic authentication
but don't offer fine-grained control over what specific actions or data
an application/service can access within the API.
API keys and JWT Bearer Authentication
• JWT(Json Web Token) Bearer Authentication
Used for both authentication and authorization
The token used for authentication/authorization is generated by a
developer portal
 It can be encrypted or digitally signed by an issuer that the service
provider trusts
It is signed using the private key and the signature is verified by the
service provider using the public key
Although a signed JWT is tamper proof, it can be used by any one that
captures it until it expires. A malicious or compromised API server
could take the JWT and replay it to other APIs to impersonate the
client.
Securing service-to-service APIs - OAuth2
OAuth2
• Widely adopted authorization framework (Not used for authentication)
• Used for authorizing for service-to-service API calls
• More secure than API keys
 It reduces the risk of exposing sensitive credentials
• Enhanced authorization than API keys
Defines what specific actions or data an application/service can access
within the API
OAuth2
• To access an API using OAuth2, an app must first obtain an access
token from the Authorization Server (AS). The app tells the AS what
scope of access it requires. The AS verifies that the user consents to
this access and issues an access token to the app. The app can then
use the access token to access the API on the user’s behalf
 Securing Microservice APIs

• Using a Service Mesh for TLS

• Locking Down Network Connections

• Securing Incoming Requests

What is a microservice?
• A microservice is an independently deployed service that is a component
of a larger application
• Microservices communicate with each other using APIs over a protocol
such as HTTP.
• We need to secure the communication between the microservices by
Using a Service Mesh for TLS
Locking Down Network Connections
Securing Incoming Requests
Kubernetes
• A Kubernetes cluster consists of a set of nodes, which are either
physical or virtual machines (VMs) running the Kubernetes software
• A pod in a single node is itself made up of one or more Linux
containers
• A microservice is implemented by one or more pod replicas – i.e. the
same microservice is replicated in the pods of different nodes, so that
if one node fails, the others can handle
Using a Service Mesh for TLS
• The microservices can be protected using TLS where a certificate is issued
for the server. The purpose of a server certificate is to prevent the client
connecting to a fake server, and it does this by authenticating the
hostname of the server.
• TLS for microservices is often implemented via a service mesh. Here, the
service mesh offers the following advantages:
Centralized Management
Automated mTLS (mutual TLS): Service meshes can automate mTLS,
where both sides of the communication (client and server) authenticate
each other.
• Example for service mesh - Istio (https://istio.io) or Linkerd
(https://linkerd.io)
Using a Service Mesh for TLS
• There are two planes in the service mesh:
Data plane – comprises the proxies and the services they protect
Control plane – comprises the components (Certificate Authority (CA))
responsible for configuring, managing, and monitoring the proxies
Using a Service Mesh for TLS
Using a Service Mesh for TLS
• A service mesh works by installing lightweight proxies as sidecar containers
into every pod in your network
• These proxies intercept all network requests coming into the pod and all
requests going out of the pod. These proxies initiate and terminate TLS,
ensuring that communications across the network.
• To make this work, the service mesh runs a central CA service (in the
control plane) that distributes certificates to the proxies. Because the
service mesh is aware of Kubernetes service metadata, it automatically
generates correct certificates for each service and can periodically reissue
them.
Locking down network connections
• Even if the TLS is enabled, an attacker can still make their own connections
to any service in the cluster
• Lateral movement is the process of an attacker moving from service to
service within your network after an initial compromise. Each new system
compromised provides new opportunities to carry out further attacks,
expanding the systems under the attacker’s control
• To make it harder for an attacker to carry out lateral movement, you can
apply network policies in Kubernetes that restrict which pods can connect to
which other pods in a network
 A Kubernetes network policy defines what network traffic is allowed into
and out of a set of pods. Traffic coming into a pod is known as ingress,
while outgoing traffic from the pod to other hosts is known as egress.
Locking down network connections
• A network policy consists of the following parts:
• A podSelector that describes which pods in the namespace the policy
will apply to. If no policies select a pod, then it will be allowed all
ingress and egress traffic
• Policy Types: This part indicates whether the policy applies to incoming
traffic (ingress), outgoing traffic (egress), or both.
• An ingress section that defines allowlist ingress rules. Each ingress rule
has a from section that says which other pods, namespaces, or IP
address ranges can make network connections to the pods in this
policy.
• An egress section that defines the allowlist egress rules. Like the ingress
rules, egress rules consist of a to section defining the allowed
destinations and a ports section defining the allowed target ports.
Network policy for the H2 database
Network policy for the H2 database
Securing incoming requests
• Service mesh and network policy secures communication between
the microservices within a cluster
• The Natter API can also be called by clients outside the cluster. In this
case, to secure the requests that are coming into the cluster, you can
enable an ingress controller
• An ingress controller is a reverse proxy or load balancer, and can be
configured to perform TLS termination, rate-limiting, audit logging,
and other basic security controls. Requests that pass these checks
are then forwarded on to the services within the network.
• Kubernetes secrets are a standard mechanism for distributing pass
words, keys, and other credentials to pods running in a cluster. The
secrets are stored in a central database and distributed to pods as
either filesystem mounts or environment variables.