OWASP - APPLICATION SECURITY RISK 2017 - CHECKLIST
A1:2017 INJECTION
VULNERABILITY
User-supplied data is not validated,
filtered, or sanitized by the
1 application
Dynamic queries or non-parameterized
calls without contextaware escaping are
2 used directly in the interpreter.
Hostile data is used within object-
relational mapping (ORM) search
parameters to extract additional, sensitive
3 records.
Hostile data is directly used or
concatenated, such that the SQL or
command contains both structure and
hostile data in dynamic queries,
4 commands, or stored procedures.
PREVENTION
The preferred option is to use a safe API,
which avoids the use of the interpreter
entirely or provides a parameterized
interface, or migrate to use Object
1 Relational Mapping Tools (ORMs)
Use positive or "whitelist" server-side
input validation. This is not a complete
defense as many applications require
special characters, such as text areas or
APIsany
2 For for residual
mobile applications
dynamic queries, escape
3 special characters using the specific
Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or
query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper
authorization.
YES NO N/A NOTE
It prevents the most common types of
vulnerabilities including Cross Site Scripting,
Injection Flaws, and Malicious File Execution.
Enforces good Software Engineering practices.
(Model-View-Controller design, Server-side form
validation, postbacks) that make the code more
No readable, scalable, and maintainable.
It prevents the most common types of vulnerabilities including Cross Site Scripting,
Injection Flaws, and Malicious File Execution. Enforces good Software Engineering
practices.
(Model-View-Controller design, Server-side form validation, postbacks) that make
NO the code more readable, scalable, and maintainable.
It prevents the most common types of
vulnerabilities including Cross Site Scripting,
Injection Flaws, and Malicious File Execution.
Enforces good Software Engineering practices.
(Model-View-Controller design, Server-side form
validation, postbacks) that make the code more
NO readable, scalable, and maintainable.
It prevents the most common types of
vulnerabilities including Cross Site Scripting,
Injection Flaws, and Malicious File Execution.
Enforces good Software Engineering practices.
(Model-View-Controller design, Server-side form
validation, postbacks) that make the code more
NO readable, scalable, and maintainable.
YES Includes a Database Abstraction Layer that writes SQL for you in real time
YES Our DB includes a Database Abstraction Layer that writes SQL for you in real time
YES Our DB includes a Database Abstraction Layer that writes SQL for you in real time
 Use LIMIT and other SQL controls within
4 queries to prevent mass disclosure of YES Our DB includes a Database Abstraction Layer that writes SQL for you in real time

A2:2017 BROKEN AUTHENTICATION Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise
passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently

VULNERABILITY
Permits automated attacks such as YES NO N/A NOTE
1 credential
Permits stuffing,
brute forcewhere theautomated
or other attacker has NO
2 attacks default, weak, or well-known
Permits NO It depends on the configuration of the web2 py application
3 passwords,
Uses weak or such as "Password1"
ineffective credential or NO We need to strengthen the application
4 recovery
Uses plainand forgotpassword
text, processes,
encrypted, or weakly NO We use an email service for user confirmation
5 hashed
Has passwords
missing (see A3:2017-Sensitive
or ineffective multi-factor NO
6 authentication.
Exposes Session IDs in the URL (e.g., URL NO
7 rewriting).
Does not rotate Session IDs after NO
8 successful
Does login invalidate Session IDs.
not properly NO
9 User sessions or authentication tokens NO
PREVENTION
Where possible, implement multi-factor
1 authentication
Do to prevent
not ship or deploy withautomated,
any default YES
2 credentials,
Implement weak-password admin
particularly for checks,users
such as YES
3 testing
Align new or changed
password passwords and
length, complexity against NO
4 rotation policies with NIST
Ensure registration, 800-63 B’s
credential YES We need to strengthen the application
5 recovery,
Limit and API pathways
or increasingly delay failedare
login YES
6 attempts.
Use Log all failures
a server-side, secure,and alertsession
built-in YES
7 manager that generates a new random YES

A3:2017 SENSITIVE DATA EXPOSURE Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify
such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra
protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser

VULNERABILITY
Is any data transmitted in clear text? This YES NO N/A NOTE
1 concerns
Are protocols
any old or weaksuch as HTTP, SMTP,
cryptographic NO
2 algorithms
Are defaultused either
crypto keysbyin default or in
use, weak NO Proxy Biella e TO5
3 crypto keys generated
Is encryption or re-used,
not enforced, orany
e.g. are is NO
4 user agent
Does the user(browser) security
agent (e.g. app,directives or
mail client) NO
5 not verify if the received server certificate NO
PREVENTION
Classify data processed, stored or
1 transmitted by an application. Identify YES
2 Apply store
Don’t controls as per data
sensitive the classification.
unnecessarily. YES
3 Discardsure
Make it astosoon as possible
encrypt or use
all sensitive PCIat
data YES
4 rest. up-to-date and strong standard
Ensure YES
5 algorithms,
Encrypt protocols,
all data andwith
in transit keyssecure
are in YES
6 protocols such as TLS with perfect forward YES
 Disable caching for response that contain
sensitive
7 Store data using strong adaptive and YES
passwords
8 salted
Verify hashing functions
independently thewith a work of YES
effectiveness
9 configuration and settings YES

A4:2017 XML EXTERNAL ENTITIES Many older or poorly configured XML processors evaluate external entity references within XML documents. 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.

VULNERABILITY
The application accepts XML directly or YES NO N/A NOTE
1 XMLof
Any uploads,
the XML especially
processorsfrom untrusted
in the NOT
2 application
If or SOAP
the application usesbased
SAML webfor services
identity NOT
3 processing
If withinuses
the application federated
SOAP security
prior to or NOT
4 version 1.2, it is likely susceptible to XXE NOT
PREVENTION
Whenever possible, use less complex data
1 formats
Patch orsuch as JSON,
upgrade andprocessors
all XML avoiding and YES
2 librariesXML
Disable in use by the entity
external application
and DTD or on the NOT
3 processing in all XML parsers in the
Implement positive (“whitelisting”) server- NOT
4 side input
Verify thatvalidation,
XML or XSLfiltering, or
file upload NOT
5 functionality
SAST tools can validates incoming
help detect XXE inXML using
source NOT
6 code, although manual code review is the NOT

A5:2017 BROKEN ACCESS CONTROL Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access
unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access
rights, etc.

VULNERABILITY
Bypassing access control checks by YES NO N/A NOTE
1 modifyingthe
Allowing theprimary
URL, internal
key to application
be changed to NO
2 another’s users record, permitting
Elevation of privilege. Acting as a user viewing NO
3 without being
Metadata logged in, or
manipulation, suchacting as an
as replaying NO
4 or tampering
CORS with a JSON
misconfiguration Web Token
allows NO
5 unauthorized
Force browsing API
toaccess
authenticated pages as NO
6 an unauthenticated user or to privileged NO
PREVENTION
With the exception of public resources,
1 deny by default.
Implement access control mechanisms YES
2 once and
Model re-use
access them throughout
controls should enforcethe YES
3 record ownership,
Unique applicationrather
businessthan accepting
limit YES
4 requirements
Disable web server directory listingbyand
should be enforced YES
5 ensure
Log file control
access metadata (e.g. .git)
failures, and
alert backup
admins YES
6 whenlimit
Rate appropriate (e.g. repeated
API and controller accessfailures)
to YES
7 minimize
JWT tokenstheshould
harm befrom automated
invalidated onattack
the YES
8 server after logout. Developers and QA YES
 A6:2017 SECURITY MISCONFIGURATION Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc
configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must
all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.

VULNERABILITY
Missing appropriate security hardening YES NO N/A NOTE
1 across any part
Unnecessary of the are
features application
enabledstack,
or or NO
2 installedaccounts
Default (e.g. unnecessary
and their ports, services,
passwords still NO
3 enabled and unchanged
Error handling reveals stack traces or NO
4 other
For overly informative
upgraded errorsecurity
systems, latest messages NO
5 features
The are disabled
security settings in orthe
notapplication
configured NO
6 servers,
The application
server does not frameworks
send security(e.g.
headers NO
7 or directives
The softwareor is they
out ofare notorset
date to secure
vulnerable NO
8 (see A9:2017-Using Components with NO
PREVENTION
A repeatable hardening process that
makes it fast and easy to deploy another
environment that is properly locked down.
Development, QA, and production
environments should all be configured
identically, with different credentials used
in each environment. This process should
be automated to minimize the effort
required to setup a new secure
1 environment
A minimal platform without any YES
2 unnecessary
A features,
task to review components,
and update the YES
3 configurations
A appropriate
segmented application to all security
architecture that YES
4 providessecurity
Sending effective, secure separation
directives to clients, YES
5 e.g.automated
An Security Headers.
process to verify the YES
6 effectiveness of the configurations and YES

A7:2017 CROSS-SITE SCRIPTING XSS XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an
existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in
the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites

VULNERABILITY
Reflected XSS: The application or API YES NO N/A NOTE
includesXSS:
1 Stored unvalidated and unescaped
The application user
or API stores NO
unsanitized
2 DOM user inputframeworks,
XSS: JavaScript that is viewed at a
single- NO
3 page applications, and APIs that NO
PREVENTION
Using frameworks that automatically
1 escape
EscapingXSS by design,
untrusted such
HTTP as the data
request latest YES
2 based on the context in the HTML output YES
 Applying context-sensitive encoding when
modifyinga the
3 Enabling browser
Content document
Security Policy on theas YES
(CSP)
4 a defense-in-depth mitigating control YES

A8:2017 INSECURE DESERIALIZATION Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be
used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks

VULNERABILITY
Object and data structure related attacks YES NO N/A NOTE
1 where
Typical dataattacker
the modifies
tampering application
attacks such as NOT
2 access-control-related
Remote- attacks
and inter-process where
communication NOT
2.1 (RPC/IPC)
Wire protocols, web services, message NOT
2.2 brokers NOT
2.3 Caching/Persistence NOT
Databases,
HTTP cache
cookies, servers,
HTML form file systems API
parameters, NOT
2.4 authentication tokens NOT
PREVENTION integrity checks such as
Implementing
1 digital signatures
Enforcing on constraints
strict type any serialized objects
during NOT
2 deserialization before object
Isolating and running code that creation as NOT
3 deserializes
Log in low privilege
deserialization exceptionsenvironments
and failures, NOT
4 such as where
Restricting the incoming
or monitoring type is and
incoming not the NOT
5 outgoing network
Monitoring connectivity
deserialization, fromif a
alerting NOT
6 user deserializes constantly. NOT

A9:2017 USING COMPONENTS WITH KNOWN Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable
VULNERABILITIES component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known
vulnerabilities may undermine application defenses and enable various attacks and impacts

VULNERABILITY YES NO N/A NOTE

Your
If youapplication
do not know is vulnerable:
the versions of all
1 components
If software is you use (both
vulnerable, client-side and
unsupported, or NO
2 out
If of do
you date.
notThis
scanincludes the OS,
for vulnerabilities NO
regularly
If and fix
you do not subscribe to security
or upgrade the underlying NO
3 platform,
If softwareframeworks,
developers do andnot
dependencies
test the NO
4 compatibility
If of updated,
you do not secure upgraded, or
the components’ NO
5 configurations (see A6:2017-Security NO
PREVENTION
Remove unused dependencies,
1 unnecessary features,
Continuously inventorycomponents,
the versions files,
of YES
2 both client-side and server-side
Only obtain components from official YES
3 sources over
Monitor secure links.
for libraries Prefer signedthat
and components YES
4 are unmaintained or do not create security YES

A10:2017 INSUFFICIENT MONITORING & Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack
LOGGING systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach
 A10:2017 INSUFFICIENT MONITORING & Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack
LOGGING systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach
is over 200 days, typically detected by external parties rather than internal processes or monitoring

VULNERABILITY
Auditable events, such as logins, failed YES NO N/A NOTE
1 logins, andand
Warnings high-value transactions
errors generate no, are not NO
2 inadequate,
Logs or unclear
of applications andlog messages
APIs are not NO
3 monitored for suspicious activity NO
4 Logs are onlyalerting
Appropriate stored locally
thresholds and NO
5 response
Penetration testing and scans are not in
escalation processes NO
6 by DAST
The tools (such
application as OWASP
is unable ZAP) do not
to detect, NO
7 escalate, or alert for active attacks in real NO
PREVENTION
Ensure all login, access control failures,
1 and server-side
Ensure that logsinput validationinfailures
are generated a format YES
2 that canhigh-value
Ensure be easily consumed
transactionsby have
a an YES
3 audit traileffective
Establish with integrity controls
monitoring andtoalerting YES
4 such that or
Establish suspicious
adopt anactivities
incident are detected
response YES
5 and recovery plan, such as NIST 800-61 rev YES