APIs are the building blocks of interoperability on the web and are a key component of scalable and successful technology companies. As externally-consumable APIs expose more information and functionality, ensuring privacy and security of customer data is an increasingly risky proposition. In this session, we’ll talk about some of Slack’s learnings around building Developer APIs and best practices for keeping your APIs safe.
Slides originally for a presentation at the Rocky Mountain Technology Summit. Slightly reduced content.
4. Every
API
needs
security.
PUBLIC
In endeavoring to expose
functionality to third-parties you blur
the perimeters of your service and
openly expose your data assets and
business capabilities.
INTERNAL / PRIVATE
Without the intention of exposing
your interfaces to third-parties, you
might work under the illusion of
security. You are still at risk.
5. OPEN APIS
68.8% of organizations are
exposing APIs to the public and
their partners.
HUGE SURFACE AREA
On average, companies
manage 363 different public-
facing APIs.
SPECIALIZATION GAP
1 in 4 companies do not treat
API security any differently
than web security.
Wehaveanopenissue.
6. The
internet
isahostile
environment.
Public by default. Gives
everyone access to over 200MM
transactions.
Venmo
An exposed and
unauthenticated API let anyone
access the personal account
details of any customer with
just their cell phone number.
Facebook
Cambridge Analytica acquired
user data through a Facebook
app developer. $37B drop in
market cap.
T-Mobile
10. COVER THE BASICS
Captain Obvious saves the da-ta. Take
the straight-forward steps to not be
an easy target.
01
APPLICATION INTERFACE
The actual APIs need to be developed
with security in mind throughout its
lifecycle.
02
EXTERNAL TOOLING
Expertise often sits outside of your
office and often the “enemy” is a
simple mistake.
04
INFRASTRUCTURE LAYER
Your data is bundled up in to small
packages. Keep them well packed to
ward off would be thieves.
03
Designing SecureAPIs
Ittakesasecurity firstmindset.
11. COVER THE BASICS
Captain Obvious saves the da-ta. Take
the straight-forward steps to not be
an easy target.
01
APPLICATION INTERFACE
The actual APIs need to be developed
with security in mind throughout its
lifecycle.
02
EXTERNAL TOOLING
Expertise often sits outside of your
office and often the “enemy” is a
simple mistake.
04
INFRASTRUCTURE LAYER
Your data is bundled up in to small
packages. Keep them well packed to
ward off would be thieves.
03
Designing SecureAPIs
Haveasecurity firstmindsetat everylayer.
12. SAY NO TO PLAIN-TEXT
It is 2018. There is no excuse.
ALWAYS HASH THEM
Hashing provides a one-way transformation of
text. You store the resulting hash and when a
user attempts to authenticate the comparison is
done by a hash on the input.
DO NOT ROLL YOUR OWN
Argon2, scrypt, bcrypt. There are many libraries
out there. Unless you are a cryptography expert
do not attempt to roll your own.
Encrypt yourpasswords. 🤫
USE A SLOW HASH
Password hashes should be slow to protect
against a “dictionary attack”. The slower the
hash, the longer it takes to run through a
dictionary.
13. HTTPS ALL THE THINGS
It is 2018. There is no excuse. HTTP traffic can
be read by anyone with network access. HTTPS
traffic can only be decrypted by the certificate
owner.
LET’S ENCRYPT IF ON A BUDGET
Let's Encrypt is a free, automated, open-source
certificate authority.
Encrypt trafficusingTLS/SSL. 🔐
14. ENCRYPTION AT REST OR BY DEFAULT
Data stored on servers is considered “at rest”.
This protects against physical theft, but also
protect against any unauthorized access to
data.
STRICTLY MANAGE ACCESS
Many small or startup companies give everyone
direct production access. While this eases
administration and overhead it is simple to
make mistakes.
STORE THE MINIMUM AMOUNT OF DATA
To borrow from the old software adage…
YAGNI. You Ain’t Gonna Need It. Store only the
data you really need to reduce risk.
ENCRYPTION / SECURITY CAN BE EASY
Many database servers can provide
application-level encryption. Google Cloud
Platform encrypts customer data stored
at rest by default.
Besmartaboutdataatrest. 💤
15.
16. 1. INJECTION
An injection of code happens when an attacker
sends invalid data to the application with the
intention of it making an action other than what
was designed.
3. SENSITIVE DATA EXPOSURE
Sensitive data may be compromised without
extra protection, such as encryption at rest or
in transit.
4. XML EXTERNAL ENTITIES (XXE)
External entities can be used to disclose
internal files using the file URI handler, internal
file shares, internal port scanning, remote code
execution, and denial of service attacks.
KnowtheOWASPTopTen. 🎳
2. BROKEN AUTHENTICATION
Weak or broken authentication mechanisms
allow an attacker to gain control over
passwords, keys, or tokens – or even worse – to
gain complete control over entire systems.
17. 5. BROKEN ACCESS CONTROL
Restrictions on what authenticated users are
allowed to do are often not properly enforced.
7. CROSS-SITE SCRIPTING (XSS)
XSS flaws occur whenever an application
includes untrusted data without proper
validation or escaping or updates an existing
web page with user-supplied data.
8. INSECURE DESERIALIZATION
Insecure deserialization often leads to remote
code execution.
KnowtheOWASPTopTen. 🎳
6. SECURITY MISCONFIGURATION
This is commonly a result of leaving default
configurations, incomplete or ad hoc
configurations, open cloud storage,
misconfigured HTTP headers, and verbose
error messages.
18. 9. USING COMPONENTS WITH KNOWN
VULNERABILITIES
Libraries, frameworks, and other components
run with the same privileges as the application.
They need to be kept up-to-date and secure.
11. CHECK PREVIOUS ISSUANCES AND
STAY UP-TO-DATE
The Open Web Application Security Project
updates the top 10 every few years. There are
still gems in the previous notices and there will
be more to come. Security is a full-time and
constant concern.
KnowtheOWASPTopTen. 🎳
10. INSUFFICIENT LOGGING AND
MONITORING
Most breach studies show time to detect a
breach is over 200 days, typically detected by
external parties rather than internal processes
or monitoring.
19. COVER THE BASICS
Captain Obvious saves the da-ta. Take
the straight-forward steps to not be
an easy target.
01
APPLICATION INTERFACE
The actual APIs need to be developed
with security in mind throughout its
lifecycle.
02
EXTERNAL TOOLING
Expertise often sits outside of your
office and often the “enemy” is a
simple mistake.
04
INFRASTRUCTURE LAYER
Your data is bundled up in to small
packages. Keep them well packed to
ward off would be thieves.
03
Designing SecureAPIs
Haveasecurity firstmindsetat everylayer.
20. The most
secureAPI
isonethat
doesnotexist.
ASK WHAT THE USE CASE IS
What problems are you trying to solve
and what functionality are you trying
to expose. Having an API for the sake
of having one is an insecure
proposition.
EXPOSE ONLY WHAT YOU NEED
Just as you should store only the data
that you need for those who need it.
Your API should only expose
information necessary to meet the use
case.
21. Ask your
clientsfor
clean
requests.
MAKE IT HARDER FOR CLIENTS
TO MAKE A MISTAKE
Provide clean documentation, URLs
that do not ask for potentially
sensitive information, ask for
timestamps, and consider publishing
a spec such as OpenAPI.
VERIFY TOWARDS THE TOP
Never trust user input. Never assume
that someone else has verified either
the request or some level of
authorization. Make these checks at
the highest levels possible.
22. IT IS SECURE UNTIL IT IS NOT
Even if your API is meant to be for internal use
or for special clients, you should verify who
that client is.
CONSIDER OAUTH
OAuth allows clients to authenticate from
another service without sharing their password
and allows API providers to grant granular
permissions.
AVOID SESSIONS WHERE POSSIBLE
Sessions leave open windows for attackers to
impersonate a real user. This state is stored
somewhere on the client where you as an API
have little control.
Alwaysauthenticate.
AT LEAST USE BASIC AUTHENTICATION
If you are exposing an internal API and want
the bare minimum consider basic
authentication with TLS / SSL. This is kind of
awful, but better than nothing!
23. SCOPE REQUEST ACCESS
Setup granular permissions for your API that
are scoped only to specific resources or
functionality.
EXPLICITLY GRANT PRIVILEGES
A client’s default access level to any resource in
the system should be DENIED unless they are
explicitly granted a PERMIT.
SEPARATION OF PRIVILEGE
Where logical, a client’s permissions should not
be based on a single condition, but rather a
combination of conditions.
Alwaysauthorize.
PRINCIPLE OF LEAST PRIVILEGE
Similarly, every client must only be able to
access the resources and functionality that are
minimally necessary for their purpose.
24. Aboutthose
keys
and
tokens.
DO NOT ASK FOR THEM IN THE
REQUEST
Keys and tokens being passed around
in URLs are ripe for being sniffed out.
Always use a POST request when
transmitting secrets over HTTP.
ENSURE THEY ARE NON-
SEQUENTIAL
This might seem silly, but use a hard
to guess key or token with a random
component.
25. A TOKEN IS JUST THAT
Once your tokens hit the database they should
have no other use other than access. Do not
reuse them as another identifier.
WATCH THE LOGS
If you employ an aggressive logging strategy
(you should) be sure to redact any secrets in
monitoring or logs.
BURN EXPOSED TOKENS
Actively pursue your rogue tokens. When you
find them delete them. NEVER COMMIT
CREDENTIALS INSIDE CODE. EVER.
Tokensafety.
DELETE UNUSED TOKENS
If a token is no longer in use disable or delete
it. This reduces the chance that an attacker that
finds a token can do anything malicious with it.
26. TOKEN NUKER
At Slack, we methodically seek out and
invalidate customers’ API tokens that have
been accidentally posted publicly. This
happens nearly every day.
WATCH THE LOGS
Most of the time a customer will ask if a token
has been used since published. But you’re
logging all the things so it’s fine.
SAVE YOUR USERS FROM THEMSELVES
Security is hard but you can make it easier for
your users by staying on top of all attack
vectors.
Nuke‘em.
AUTOMATE IT
Token discovery is automated as is the follow-
up notification to the customer.
27. Deliver clean
responses.
PUBLISH A SPEC
Standards, specs, and consistency
help API authors and consumers alike
in sending intentional responses as
well as accepting only the information
necessary.
MIND THE HEADERS
People often focus on the actual
payload of responses, but a lot of
hidden information goes in to HTTP
Headers. Be sure you know what is
being included all the way at the
other end.
28. KISS
Keep it simple Steven. Clear and concise errors
are the most helpful for clients. They also
happen to be the most secure.
DO NOT LEAK YOUR DATA MODELS
A well designed API is focused on client or
developer use cases, not exposing your
underlying architecture.
DO NOT LEAK YOUR STACK TRACES
If you are using a framework, overwrite the
default error pages and make sure you are
running in production mode and not exposing
the underlying code.
Respondwith simple andintentionalerrors.
HIDE YOUR CLUES
Those errors are secure of course, only if you
do not provide hints to a would be attacker
looking for clues.
29. Log
and
Audit
ALLTHE
THINGS.
SERIOUSLY, EVERYTHING
Having a continuous and detailed
stream of events helps not only in
detecting anomalies, but responding
to a potential incident with speed.
STRUCTURE IS HELPFUL
Consider structured logging (JSON
perhaps) to help aide in searching for
the right data.
30. Rate
Limit
ALLTHE
THINGS.
USAGE QUOTAS
The most basic rate limiting schemes
limit clients by allowing clients to
send “x requests per second”.
RESOURCE QUOTAS
More advanced strategies for rate
limiting include throttling based on
the expense of the request or the
frequency of need for the use case.
31. Donotforget
aboutyour
ownlimits.
EVERYTHING IN MODERATION
Many APIs today include event-driven interfaces such as webhooks or other streams. A
sudden forced burst of activity in your service can easily take down your service or leave it
in an otherwise degraded state.
32.
33. IP WHITELISTING
At Slack, we allow customers to configure a set
of static IPs from which we will know that they
are sending traffic.
MUTUAL TLS
If you can run your own TLS-terminating server,
you can obtain a shared secret with another
individual organization to verify their identity.
INTERNAL BLACKLISTING
Over time you can collect a list of bad actors
and immediately reject their traffic. This is a
necessarily a cat and mouse game but there are
smart ways to respond.
Provide methodstotrusttraffic.
REQUEST SIGNING
You can use a pre-determined shared secret to
hash a request against.
34. COVER THE BASICS
Captain Obvious saves the da-ta. Take
the straight-forward steps to not be
an easy target.
01
APPLICATION INTERFACE
The actual APIs need to be developed
with security in mind throughout its
lifecycle.
02
EXTERNAL TOOLING
Expertise often sits outside of your
office and often the “enemy” is a
simple mistake.
04
INFRASTRUCTURE LAYER
Your data is bundled up in to small
packages. Keep them well packed to
ward off would be thieves.
03
Designing SecureAPIs
Haveasecurity firstmindsetat everylayer.
35. Test
Test
Test
AUTOMATE ANYTHING YOU CAN
Test your APIs constantly and preferably at their furthest stage from production. A spec
like OpenAPI and following a JSON Schema can help you detect changes to your API and
unintended exposure of data.
36. SERVER BASICS
Lock down your ports and server access. API
security depends on overall security of your
entire stack.
NETWORK FIREWALL
Tune and configure your connectivity policies
to monitor and protect your application
servers.
WEB APPLICATION FIREWALL
Use IaaS or other software to monitor and
block traffic and protect against DDoS attacks.
DeploysmartinfratoshieldyourAPIs.
API GATEWAY
Isolate your API traffic. This can either be done
by code architecture or putting another layer of
abstraction in front of the rest of your
infrastructure.
37. COVER THE BASICS
Captain Obvious saves the da-ta. Take
the straight-forward steps to not be
an easy target.
01
APPLICATION INTERFACE
The actual APIs need to be developed
with security in mind throughout its
lifecycle.
02
EXTERNAL FACTORS
Expertise often sits outside of your
office and often the “enemy” is a
simple mistake.
04
INFRASTRUCTURE LAYER
Your data is bundled up in to small
packages. Keep them well packed to
ward off would be thieves.
03
Designing SecureAPIs
Haveasecurity firstmindsetat everylayer.
38. Donotroll
yourown.
LEAN ON OPEN SOURCE
There are a plethora of Open Source tools and libraries that relate to secure
implementations and to ensure API security. The community at large shares expertise,
helps find bugs, and wider usage helps test in the wild. Don’t forget to keep these tools
and libraries up-to-date. Use with caution of course…
39. Enforce
policies ina
consistentand
timely manner.
POLICY AND LEGAL
At Slack, our Policy and Legal teams are also included in the Developer Platform and
Security cross-functional groups. Terms of Services and Acceptable Use Case policies are
increasingly important as you expose more data. Action needs to be taken swiftly and
applied consistently.
40.
41. Partner
acrossthe
organization.
SECURITY DEVELOPMENT LIFECYCLE
Our product and infrastructure
engineering teams have partnered
with the security org to review projects.
This is both procedural and educational!
SECURITY WEEK
Once a year, Slack holds a security week
where we compete in Capture The Flag,
a security training platform, and hold
other classes like lock-picking.
42. APP DIRECTORY REVIEW
This is a requirement of listing. It is a
combination of automated scanning processes,
limiting scopes, and manual reviews of
architecture, authentication, and misuse.
SHARE BEST PRACTICES
We come across common mistakes and
patterns and these go in to not only our
documentation, but in hands-on help at our
developer focused events.
Partnerwithyourdevelopers.
CHECK AGAIN
We regularly follow up with scans and employ
external vendors to also do periodic reviews.
44. REAL ATTACKS
Even if you have an internal security
organization, it is always to get real help from
the outside. Outside pen-testing vendors try to
expose real vulnerabilities without inside
knowledge.
BE PREPARED AND WORK CLOSELY
The best case scenario is that you have paid a
vendor money and they have found nothing.
They will certainly try. The worst case is you will
need to be prepared to respond.
MULTIPLE VENDORS
The strengths, quality, and speed of reporting
and assessment varies widely. If you have the
budget, compare multiple pen-testing vendors.
Asktobehacked.
SAFE ATTACKS
Generally external security testing vendors will
run automation in non-critical business hours or
will limit the speed of their automation. Their
exploits will also be relatively “safe”.
45. BUG BOUNTY
Real vulnerabilities and reports from external
security researchers. Slack is listed on
HackerOne.
PAY
Over the last 4 years, Slack has paid out over
$300k in rewards. You can set the tiers and
payouts.
ESTABLISH SLAS
Once bugs come in, make sure there is
accountability in getting security issues
resolved expediently.
Asktobehackedmore.
RESPOND
We judge the quality of our communication
with researchers by our response times. In
addition to accountability, it builds overall trust
in the community.
46.
47. Plan
your
response.
HAVE A RUNBOOK
Have step-by-step procedures with
Directly Responsible Individuals and
communication plans. Hopefully you
will never need this but it will be
crucial if you do.
PRACTICE MAKES PERFECT
Runbooks are only useful when you’re
running. Consider running drills for
incidents, whether operational or
security to make sure you work out
those response muscles.
