The Open Web Application Security Project, or OWASP, is an international non-profit organization dedicated to web application security. One of OWASP’s core principles is that all of their materials be freely available and easily accessible on their website, making it possible for anyone to improve their own web application security. The materials they offer include documentation, tools, videos, and forums. Perhaps their best-known project is the OWASP Top 10.

2. DYNAMIC WEB APPLICATIONS OCCASIONALLY NEED TO RUN
COMMANDS ON THE UNDERLYING DATABASE OR OPERATING
SYSTEM TO UPDATE DATA, EXECUTE A SCRIPT OR START OTHER
APPS. IF UNVALIDATED INPUTS ARE ADDED TO A COMMAND
STRING, ATTACKERS CAN LAUNCH COMMANDS AT WILL TO TAKE
CONTROL OF A SERVER, DEVICE OR DATA.
IF A WEBSITE, APP, OR DEVICE INCORPORATES USER INPUT WITHIN A
COMMAND, AN ATTACKER CAN INSERT A “PAYLOAD” COMMAND DIRECTLY INTO
SAID INPUT. IF THAT INPUT IS NOT VERIFIED, AN ATTACKER THEN “INJECTS” AND
RUNS THEIR OWN COMMANDS. ONCE ATTACKERS CAN MAKE COMMANDS,
THEY CAN CONTROL YOUR WEBSITE, APPS AND DATA.

3. • USER-SUPPLIED DATA IS NOT VALIDATED, FILTERED, OR SANITIZED BY THE APPLICATION
• DYNAMIC QUERIES OR NON-PARAMETERIZED CALLS WITHOUT CONTEXT AWARE ESCAPING ARE USED
DIRECTLY IN THE INTERPRETER.
• HOSTILE DATA IS USED WITHIN OBJECT-RELATIONAL MAPPING (ORM) SEARCH PARAMETERS TO EXTRACT
ADDITIONAL, SENSITIVE RECORDS.
• HOSTILE DATA IS DIRECTLY USED OR CONCATENATED, SUCH THAT THE SQL OR COMMAND CONTAINS BOTH
STRUCTURE AND HOSTILE DATA IN DYNAMIC QUERIES, COMMANDS, OR STORED PROCEDURES.

4. • USE A SAFE API, WHICH AVOIDS THE USE OF THE INTERPRETER ENTIRELY OR PROVIDES A PARAMETERIZED
INTERFACE OR MIGRATE TO USE OBJECT RELATIONAL MAPPING TOOLS (ORMS).
• USE POSITIVE OR “WHITELIST” SERVER-SIDE INPUT VALIDATION
• USE LIMIT AND OTHER SQL CONTROLS WITHIN QUERIES TO PREVENT MASS DISCLOSURE OF RECORDS IN
CASE OF SQL INJECTION.
• ENSURE THAT THE WEB APPLICATION RUNS WITH ONLY THE PRIVILEGES IT ABSOLUTELY NEEDS TO
PERFORM ITS FUNCTION.

5. INCORRECT IMPLEMENTATION OF AUTHENTICATION AND SESSION MANAGEMENT FUNCTIONS IN APPLICATIONS ALLOWS
ATTACKERS TO COMPROMISE DATA SUCH AS PASSWORDS, KEYS AND SESSION TOKENS OR TO EXPLOIT OTHER
IMPLEMENTATION FLAWS TO MASQUERADE IDENTITIES TEMPORARILY OR PERMANENTLY.
ATTACKERS HAVE ACCESS TO MILLIONS OF VALID USERNAME AND PASSWORD COMBINATIONS WHICH CAN BE USED IN
CREDENTIAL STUFFING, DEFAULT ADMINISTRATIVE ACCOUNT LISTS, AUTOMATED BRUTE FORCE AND DICTIONARY ATTACK
TOOLS. UNEXPIRED SESSION TOKENS DUE TO POOR SESSION MANAGEMENT IS THE MAIN VULNERABILITY BEHIND
SESSION MANAGEMENT ATTACKS.
IN THE SIMPLEST ATTACKS, PASSWORDS CAN BE GUESSED OR STOLEN IF LEFT UNPROTECTED. AS
COMPLEXITIES ARE ADDED, ATTACKERS CAN FIND OTHER AREAS WHERE USER CREDENTIALS OR SESSIONS
HAVE INADEQUATE PROTECTIONS AND THEN HIJACK A USER’S ACCESS, AND EVENTUALLY THEIR DATA.

6. • PERMITS AUTOMATED ATTACKS SUCH AS CREDENTIAL STUFFING, WHERE THE ATTACKER HAS A LIST OF VALID
USERNAMES AND PASSWORDS.
• PERMITS BRUTE FORCE OR OTHER AUTOMATED ATTACKS.
• PERMITS DEFAULT, WEAK, OR WELL-KNOWN PASSWORDS, SUCH AS”PASSWORD1″ OR “ADMIN/ADMIN“.
• USES WEAK OR INEFFECTIVE CREDENTIAL RECOVERY AND FORGOT-PASSWORD PROCESSES, SUCH AS “KNOWLEDGE-
BASED ANSWERS”, WHICH CANNOT BE MADE SAFE.
• USES PLAIN TEXT, ENCRYPTED, OR WEAKLY HASHED PASSWORDS.
• HAS MISSING OR INEFFECTIVE MULTI-FACTOR AUTHENTICATION.
• EXPOSES SESSION IDS IN THE URL (E.G., URL REWRITING).
• DOES NOT ROTATE SESSION IDS AFTER SUCCESSFUL LOGIN.
• DOES NOT PROPERLY INVALIDATE SESSION IDS. USER SESSIONS OR AUTHENTICATION TOKENS (PARTICULARLY SINGLE
SIGN-ON (SSO) TOKENS) AREN’T PROPERLY INVALIDATED DURING LOGOUT OR A PERIOD OF INACTIVITY.

7. • WHERE POSSIBLE, IMPLEMENT MULTI-FACTOR AUTHENTICATION TO PREVENT AUTOMATED, CREDENTIAL STUFFING,
BRUTE FORCE, AND STOLEN CREDENTIAL RE-USE ATTACKS.
• DO NOT SHIP OR DEPLOY WITH ANY DEFAULT CREDENTIALS, PARTICULARLY FOR ADMIN USERS.
• IMPLEMENT WEAK-PASSWORD CHECKS, SUCH AS TESTING NEW OR CHANGED PASSWORDS AGAINST A LIST OF THE
TOP 10000 WORST PASSWORDS.
• ALIGN PASSWORD LENGTH, COMPLEXITY AND ROTATION POLICIES WITH NIST 800-63 B’S GUIDELINES IN SECTION
5.1.1 FOR MEMORIZED SECRETS OR OTHER MODERN, EVIDENCE-BASED PASSWORD POLICIES.
• ENSURE REGISTRATION, CREDENTIAL RECOVERY, AND API PATHWAYS ARE HARDENED AGAINST ACCOUNT
ENUMERATION ATTACKS BY USING THE SAME MESSAGES FOR ALL OUTCOMES.
• LIMIT OR INCREASINGLY DELAY FAILED LOGIN ATTEMPTS. LOG ALL FAILURES AND ALERT ADMINISTRATORS WHEN
CREDENTIAL STUFFING, BRUTE FORCE, OR OTHER ATTACKS ARE DETECTED.
• USE A SERVER-SIDE, SECURE, BUILT-IN SESSION MANAGER THAT GENERATES A NEW RANDOM SESSION ID WITH HIGH
ENTROPY AFTER LOGIN. SESSION IDS SHOULD NOT BE IN THE URL. IDS SHOULD ALSO BE SECURELY STORED AND
INVALIDATED AFTER LOGOUT, IDLE, AND ABSOLUTE TIMEOUTS.

8. SENSITIVE DATA, SUCH AS CREDIT CARD NUMBERS, HEALTH
DATA, OR PASSWORDS, SHOULD HAVE EXTRA PROTECTION
GIVEN THE POTENTIAL OF DAMAGE IF IT FALLS INTO THE
WRONG HANDS. THERE ARE EVEN REGULATIONS AND
STANDARDS DESIGNED TO PROTECT SENSITIVE DATA. BUT, IF
SENSITIVE DATA IS STORED, TRANSMITTED, OR PROTECTED BY
INADEQUATE METHODS, IT CAN BE EXPOSED TO ATTACKERS.
IF DATA IS STORED OR TRANSFERRED AS PLAIN TEXT, IF OLDER/WEAKER ENCRYPTION IS USED, OR IF DATA IS
DECRYPTED CARELESSLY, ATTACKERS CAN GAIN ACCESS AND EXPLOIT THE DATA. ONCE AN ATTACKER HAS
PASSWORDS AND CREDIT CARD NUMBERS, THEY CAN DO REAL DAMAGE .

9. • THE MOST COMMON FLAW IS SIMPLY NOT ENCRYPTING SENSITIVE DATA.
• DEFAULT CRYPTO KEYS IN USE, WEAK CRYPTO KEYS GENERATED, RE-USED, AND PROPER KEY
MANAGEMENT AND ROTATION MISSING
• NOT ENCRYPTING SENSITIVE DATA IS THE MAIN REASON WHY THESE ATTACKS ARE STILL SO
WIDESPREAD. EVEN ENCRYPTED DATA CAN BE BROKEN DUE TO WEAK:
• KEY GENERATION PROCESS;
• KEY MANAGEMENT PROCESS;
• ALGORITHM USAGE;
• PROTOCOL USAGE;
• CIPHER USAGE;
• PASSWORD HASHING STORAGE TECHNIQUES.

10. • CLASSIFY DATA PROCESSED, STORED, OR TRANSMITTED BY AN APPLICATION.
• IDENTIFY WHICH DATA IS SENSITIVE ACCORDING TO PRIVACY LAWS, REGULATORY REQUIREMENTS, OR BUSINESS NEEDS.
• APPLY CONTROLS AS PER THE CLASSIFICATION.
• DON’T STORE SENSITIVE DATA UNNECESSARILY.
• DISCARD IT AS SOON AS POSSIBLE OR USE PCI DSS COMPLIANT TOKENIZATION OR EVEN TRUNCATION. DATA THAT IS NOT
RETAINED CANNOT BE STOLEN.
• MAKE SURE TO ENCRYPT ALL SENSITIVE DATA AT REST.
• ENSURE UP-TO-DATE AND STRONG STANDARD ALGORITHMS, PROTOCOLS, AND KEYS ARE IN PLACE; USE PROPER KEY
MANAGEMENT.
• ENCRYPT ALL DATA IN TRANSIT WITH SECURE PROTOCOLS SUCH AS TLS WITH PERFECT FORWARD SECRECY (PFS) CIPHERS,
CIPHER PRIORITIZATION BY THE SERVER, AND SECURE PARAMETERS.
• ENFORCE ENCRYPTION USING DIRECTIVES LIKE HTTP STRICT TRANSPORT SECURITY (HSTS).

11. XML EXTERNAL ENTITY INJECTION IS ALSO KNOWN AS XXE IS AN ATTACK BASED ON SERVER-SIDE REQUEST
FORGERY (SSRF). XXE ATTACK MANIPULATES A RARELY USED FEATURE OF XML PARSERS TO DO DENIAL OF
SERVICE ATTACKS, GAIN ACCESS TO LOCAL AND REMOTE CONTENT AND SERVICES AND REMOTE CODE
EXECUTION. THERE ARE TWO TYPES OF XXE ATTACKS AS IN-BAND AND OUT-OF-BAND.
AN ATTACKER SENDS MALICIOUS DATA LOOKUP VALUES ASKING THE
SITE, DEVICE, OR APP TO REQUEST AND DISPLAY DATA FROM A LOCAL
FILE. IF A DEVELOPER USES A COMMON OR DEFAULT FILENAME IN A
COMMON LOCATION, AN ATTACKER’S JOB IS EASY.

12. • THE APPLICATION ACCEPTS XML DIRECTLY OR XML UPLOADS, ESPECIALLY FROM UNTRUSTED
SOURCES, OR INSERTS UNTRUSTED DATA INTO XML DOCUMENTS, WHICH IS THEN PARSED BY AN
XML PROCESSOR.
• ANY OF THE XML PROCESSORS IN THE APPLICATION OR SOAP BASED WEB SERVICES HAS
DOCUMENT TYPE DEFINITIONS (DTDS) ENABLED.
• IF YOUR APPLICATION USES SAML FOR IDENTITY PROCESSING WITHIN FEDERATED SECURITY OR
SINGLE SIGN ON (SSO) PURPOSES. SAML USES XML FOR IDENTITY ASSERTIONS, AND MAY BE
VULNERABLE.
• IF THE APPLICATION USES SOAP PRIOR TO VERSION 1.2, IT IS LIKELY SUSCEPTIBLE TO XXE
ATTACKS IF XML ENTITIES ARE BEING PASSED TO THE SOAP FRAMEWORK.

13. • WHENEVER POSSIBLE, USE LESS COMPLEX DATA FORMATS SUCH AS JSON, AND AVOID SERIALIZATION OF SENSITIVE DATA.
• PATCH OR UPGRADE ALL XML PROCESSORS AND LIBRARIES IN USE BY THE APPLICATION OR ON THE UNDERLYING
OPERATING SYSTEM.
• USE DEPENDENCY CHECKERS (UPDATE SOAP TO SOAP 1.2 OR HIGHER).
• DISABLE XML EXTERNAL ENTITY AND DTD PROCESSING IN ALL XML PARSERS IN THE APPLICATION, AS PER THE OWASP
CHEAT SHEET ‘XXE PREVENTION’.
• IMPLEMENT POSITIVE (“WHITELISTING”) SERVER-SIDE INPUT VALIDATION, FILTERING, OR SANITIZATION TO PREVENT
HOSTILE DATA WITHIN XML DOCUMENTS, HEADERS, OR NODES.
• VERIFY THAT XML OR XSL FILE UPLOAD FUNCTIONALITY VALIDATES INCOMING XML USING XSD VALIDATION OR
SIMILAR.
• SAST TOOLS CAN HELP DETECT XXE IN SOURCE CODE – ALTHOUGH MANUAL CODE REVIEW IS THE BEST ALTERNATIVE IN
LARGE, COMPLEX APPLICATIONS WITH MANY INTEGRATIONS.

14. ACCESS CONTROL IS THERE TO RESTRICT ACCESS ON DATA AND FUNCTIONS FOR UNWANTED
PARTIES. IF ACCESS CONTROL IS NOT IMPLEMENTED PROPERLY IT WILL LEAD TO BROKEN
ACCESS CONTROL WHICH ALLOWS ATTACKERS TO EXPLOIT VULNERABILITY TO ACCESS
UNAUTHORIZED CRITICAL DATA AND FUNCTIONS.
SOMETIMES, GAINING UNAUTHORIZED ACCESS IS AS
SIMPLE AS MANUALLY ENTERING AN UNLINKED URL
IN A BROWSER, SUCH AS,
HTTP://EXAMPLE.COM/ADMIN..

15. • BYPASSING ACCESS CONTROL CHECKS BY MODIFYING THE URL, INTERNAL APPLICATION STATE, OR THE HTML
PAGE, OR SIMPLY USING A CUSTOM API ATTACK TOOL
• ALLOWING THE PRIMARY KEY TO BE CHANGED TO ANOTHER'S USERS RECORD, PERMITTING VIEWING OR EDITING
SOMEONE ELSE'S ACCOUNT.
• ELEVATION OF PRIVILEGE. ACTING AS A USER WITHOUT BEING LOGGED IN, OR ACTING AS AN ADMIN WHEN
LOGGED IN AS A USER.
• METADATA MANIPULATION, SUCH AS REPLAYING OR TAMPERING WITH A JSON WEB TOKEN (JWT) ACCESS
CONTROL TOKEN OR A COOKIE OR HIDDEN FIELD MANIPULATED TO ELEVATE PRIVILEGES, OR ABUSING JWT
INVALIDATION
• CORS MISCONFIGURATION ALLOWS UNAUTHORIZED API ACCESS.
• FORCE BROWSING TO AUTHENTICATED PAGES AS AN UNAUTHENTICATED USER OR TO PRIVILEGED PAGES AS A
STANDARD USER. ACCESSING API WITH MISSING ACCESS CONTROLS FOR POST, PUT AND DELETE.

16. • WITH THE EXCEPTION OF PUBLIC RESOURCES, DENY BY DEFAULT.
• IMPLEMENT ACCESS CONTROL MECHANISMS ONCE AND RE-USE THEM THROUGHOUT THE APPLICATION, INCLUDING
MINIMIZING CORS USAGE.
• MODEL ACCESS CONTROLS SHOULD ENFORCE RECORD OWNERSHIP, RATHER THAN ACCEPTING THAT THE USER CAN
CREATE, READ, UPDATE, OR DELETE ANY RECORD.
• UNIQUE APPLICATION BUSINESS LIMIT REQUIREMENTS SHOULD BE ENFORCED BY DOMAIN MODELS.
• DISABLE WEB SERVER DIRECTORY LISTING AND ENSURE FILE METADATA (E.G. .GIT) AND BACKUP FILES ARE NOT PRESENT
WITHIN WEB ROOTS.
• LOG ACCESS CONTROL FAILURES, ALERT ADMINS WHEN APPROPRIATE (E.G. REPEATED FAILURES).
• RATE LIMIT API AND CONTROLLER ACCESS TO MINIMIZE THE HARM FROM AUTOMATED ATTACK TOOLING.
• JWT TOKENS SHOULD BE INVALIDATED ON THE SERVER AFTER LOGOUT.

17. SECURITY MISCONFIGURATION IS THE MOST COMMON VULNERABILITY ON THE LIST, AND IS OFTEN THE
RESULT OF USING DEFAULT CONFIGURATIONS OR DISPLAYING EXCESSIVELY VERBOSE ERRORS. FOR
INSTANCE, AN APPLICATION COULD SHOW A USER OVERLY-DESCRIPTIVE ERRORS WHICH MAY REVEAL
VULNERABILITIES IN THE APPLICATION. THIS CAN BE MITIGATED BY REMOVING ANY UNUSED FEATURES
IN THE CODE AND ENSURING THAT ERROR MESSAGES ARE MORE GENERAL.
PEOPLE GET BUSY, THINGS GET MISSED, PRIORITIZATION DECISIONS ARE MADE. AND VULNERABILITIES ARE
LEFT UNCHECKED.

18. • UNNECESSARY FEATURES ARE ENABLED OR INSTALLED (E.G. UNNECESSARY PORTS, SERVICES,
PAGES, ACCOUNTS, OR PRIVILEGES)
• ERROR HANDLING REVEALS STACK TRACES OR OTHER OVERLY INFORMATIVE ERROR MESSAGES TO
USERS.
• THE SERVER DOES NOT SEND SECURITY HEADERS OR DIRECTIVES OR THEY ARE NOT SET TO
SECURE VALUES.
• DEFAULT ACCOUNTS AND THEIR PASSWORDS STILL ENABLED AND UNCHANGED.
• FOR UPGRADED SYSTEMS, LATEST SECURITY FEATURES ARE DISABLED OR NOT CONFIGURED
SECURELY.

19. • A MINIMAL PLATFORM WITHOUT ANY UNNECESSARY FEATURES, COMPONENTS, DOCUMENTATION,
AND SAMPLES.
• REMOVE OR DO NOT INSTALL UNUSED FEATURES AND FRAMEWORKS.
• AN AUTOMATED PROCESS TO VERIFY THE EFFECTIVENESS OF THE CONFIGURATIONS AND SETTINGS IN
ALL ENVIRONMENTS. .
• AN AUTOMATED PROCESS TO VERIFY THE EFFECTIVENESS OF THE CONFIGURATIONS AND SETTINGS IN
ALL ENVIRONMENTS.

20. CROSS-SITE SCRIPTING VULNERABILITIES OCCUR WHEN WEB APPLICATIONS ALLOW USERS TO
ADD CUSTOM CODE INTO A URL PATH OR ONTO A WEBSITE THAT WILL BE SEEN BY OTHER
USERS. THIS VULNERABILITY CAN BE EXPLOITED TO RUN MALICIOUS JAVASCRIPT CODE ON A
VICTIM’S BROWSER.
WHEN A WEB PAGE OR APP UTILIZES USER-ENTERED CONTENT AS PART OF A
RESULTING PAGE WITHOUT CHECKING FOR BAD STUFF, A MALICIOUS USER COULD
ENTER CONTENT THAT INCLUDES HTML ENTITIES.

21. THERE ARE THREE FORMS OF XSS ,
• REFLECTED XSS: AN XSS ALLOWS AN ATTACKER TO INJECT A SCRIPT INTO THE CONTENT OF A WEBSITE OR
APP. WHEN A USER VISITS THE INFECTED PAGE, THE SCRIPT WILL EXECUTE IN THE VICTIM’S BROWSER. THIS
ALLOWS ATTACKERS TO STEAL PRIVATE INFORMATION LIKE COOKIES, ACCOUNT INFORMATION, OR TO PERFORM
CUSTOM OPERATIONS WHILE IMPERSONATING THE VICTIM’S IDENTITY.
• STORES XSS: THE MOST DANGEROUS TYPE OF XSS INJECTION, REQUIRES SERVER SIDE INTERPRETATION OF
THE QUERY .IT OCCURS WHEN THE DATA PROVIDED BY THE ATTACKER IS SAVED BY THE SERVER.
• DOM XSS: APPEARS IN THE DOM (DOCUMENT OBJECT MODEL) INSTEAD OF PART OF THE HTML. DOM
BASED CROSS-SITE SCRIPTING, THE HTML SOURCE CODE AND RESPONSE OF THE ATTACK WILL BE EXACTLY THE
SAME, THEREFOR THE PAYLOAD CANNOT BE FOUND IN THE RESPONSE. IT CAN ONLY BE OBSERVED ON
RUNTIME OR BY INVESTIGATING THE DOM OF THE PAGE.

22. • TAKING THE DATA AN APPLICATION HAS RECEIVED AND ENSURING IT’S SECURE BEFORE RENDERING IT
FOR THE END USER.
• BY ESCAPING USER INPUT, KEY CHARACTERS IN THE DATA RECEIVED BY A WEB PAGE WILL BE
PREVENTED FROM BEING INTERPRETED IN ANY MALICIOUS WAY
• ENSURING AN APPLICATION IS RENDERING THE CORRECT DATA AND PREVENTING MALICIOUS DATA
FROM DOING HARM TO THE SITE, DATABASE, AND USERS.
• WHILE WHITELISTING AND INPUT VALIDATION ARE MORE COMMONLY ASSOCIATED WITH SQL
INJECTION, THEY CAN ALSO BE USED AS AN ADDITIONAL METHOD OF PREVENTION FOR XSS
• SANITIZING DATA IS A STRONG DEFENSE, BUT SHOULD NOT BE USED ALONE TO BATTLE XSS ATTACKS.

23. DESERIALIZED DATA CAN BE MODIFIED TO INCLUDE
MALICIOUS CODE, WHICH IS LIKELY TO CAUSE ISSUES IF
THE APPLICATION DOES NOT VERIFY THE DATA’S SOURCE
OR CONTENTS BEFORE DESERIALIZATION. ATTACKERS CAN
BUILD ILLEGITIMATE OBJECTS THAT EXECUTE COMMANDS
WITHIN AN INFECTED APPLICATION .
BEFORE DATA IS STORED OR TRANSMITTED, THE BITS ARE OFTEN SERIALIZED SO THAT THEY CAN BE
LATER RESTORED TO THE DATA’S ORIGINAL STRUCTURE. REASSEMBLING A SERIES OF BITS BACK INTO A
FILE OR OBJECT IS CALLED DESERIALIZATION.

24. • IT IS HARD TO DETECT ATTACKS CAUSED BY INSECURE DESERIALIZATION SINCE THE PROCESS OF
DESERIALIZATION USES COMMON CODE LIBRARIES FOUND IN WEB DEVELOPMENT.
• HOWEVER, SOME WAYS TO HELP IDENTIFY INSECURE DESERIALIZATION INCLUDE
• CHECK DESERIALIZATIONS TO SEE IF THE DATA IS CORRECTLY HANDLED AS USER INPUT INSTEAD OF TRUSTED
INTERNAL DATA.
• CHECK DESERIALIZATIONS TO ENSURE THE DATA IS WHAT IT IS SUPPOSED TO BE BEFORE BEING USED.
• RUN SECURITY SCANS REGULARLY.
• USE A MONITORING TOOL SUCH AS DETECTIFY OR THREAT STACK TO MONITOR DESERIALIZATIONS AND SET
NOTIFICATIONS FOR COMMON VULNERABLE COMPONENTS.

25. • WAYS TO AVOID INSECURE DESERIALIZATION INCLUDE:
• MONITORING THE DESERIALIZATION PROCESS.
• ENCRYPTING SERIALIZATION PROCESSES.
• NOT ACCEPTING SERIALIZED OBJECTS FROM UNKNOWN OR UNTRUSTED SOURCES.
• RUNNING THE DESERIALIZATION CODE WITH LIMITED ACCESS PERMISSIONS.
• USING A FIREWALL WHICH CAN HELP DETECT INSECURE DESERIALIZATION.

26. MANY MODERN WEB DEVELOPERS USE COMPONENTS SUCH AS LIBRARIES AND FRAMEWORKS IN THEIR WEB
APPLICATIONS. THESE COMPONENTS ARE PIECES OF SOFTWARE THAT HELP DEVELOPERS AVOID REDUNDANT
WORK AND PROVIDE NEEDED FUNCTIONALITY; COMMON EXAMPLE INCLUDE FRONT-END FRAMEWORKS LIKE
REACT AND SMALLER LIBRARIES THAT USED TO ADD SHARE ICONS OR A/B TESTING. SOME ATTACKERS LOOK
FOR VULNERABILITIES IN THESE COMPONENTS WHICH THEY CAN THEN USE TO ORCHESTRATE ATTACKS.

27. • IF SOFTWARE IS VULNERABLE, UNSUPPORTED, OR OUT OF DATE. THIS INCLUDES THE OS,
WEB/APPLICATION SERVER, DATABASE MANAGEMENT SYSTEM (DBMS), APPLICATIONS,
AND ALL COMPONENTS, RUNTIME ENVIRONMENTS, AND LIBRARIES.
• IF YOU DO NOT SCAN FOR VULNERABILITIES REGULARLY AND SUBSCRIBE TO SECURITY
BULLETINS RELATED TO THE COMPONENTS YOU USE.
• IF SOFTWARE DEVELOPERS DO NOT TEST THE COMPATIBILITY OF UPDATED, UPGRADED, OR
PATCHED LIBRARIES
• IF YOU DO NOT FIX OR UPGRADE THE UNDERLYING PLATFORM, FRAMEWORKS, AND
DEPENDENCIES IN A RISK-BASED, TIMELY FASHION.

28. • REMOVE UNUSED DEPENDENCIES, UNNECESSARY FEATURES, COMPONENTS, FILES, AND
DOCUMENTATION.
• CONTINUOUSLY INVENTORY THE VERSIONS OF BOTH CLIENT-SIDE AND SERVER-SIDE COMPONENTS
(E.G. FRAMEWORKS, LIBRARIES).
• ONLY OBTAIN COMPONENTS FROM OFFICIAL SOURCES OVER SECURE LINKS.
• MONITOR FOR LIBRARIES AND COMPONENTS THAT ARE UNMAINTAINED OR DO NOT CREATE
SECURITY PATCHES FOR OLDER VERSIONS.

29. MANY WEB APPLICATIONS ARE NOT TAKING ENOUGH STEPS TO DETECT DATA BREACHES. THE AVERAGE
DISCOVERY TIME FOR A BREACH IS AROUND 200 DAYS AFTER IT HAS HAPPENED. THIS GIVES ATTACKERS
A LOT OF TIME TO CAUSE DAMAGE BEFORE THERE IS ANY RESPONSE. OWASP RECOMMENDS THAT
WEB DEVELOPERS SHOULD IMPLEMENT LOGGING AND MONITORING AS WELL AS INCIDENT RESPONSE
PLANS TO ENSURE THAT THEY ARE MADE AWARE OF ATTACKS ON THEIR APPLICATIONS.

30. • AUDITABLE EVENTS, SUCH AS LOGINS, FAILED LOGINS, AND HIGH-VALUE TRANSACTIONS ARE NOT
LOGGED.
• LOGS ARE ONLY STORED LOCALLY.
• THE APPLICATION IS UNABLE TO DETECT, ESCALATE, OR ALERT FOR ACTIVE ATTACKS IN REAL TIME
OR NEAR REAL TIME.
• WARNINGS AND ERRORS GENERATE NO, INADEQUATE, OR UNCLEAR LOG MESSAGES

31. • ENSURE THAT LOGS ARE GENERATED IN A FORMAT THAT CAN BE EASILY CONSUMED BY A
CENTRALIZED LOG MANAGEMENT SOLUTIONS.
• ESTABLISH EFFECTIVE MONITORING AND ALERTING SUCH THAT SUSPICIOUS ACTIVITIES ARE
DETECTED AND RESPONDED TO IN A TIMELY FASHION.
• ENSURE ALL LOGIN, ACCESS CONTROL FAILURES, AND SERVER-SIDE INPUT VALIDATION
FAILURES CAN BE LOGGED WITH SUFFICIENT USER CONTEXT TO IDENTIFY SUSPICIOUS OR
MALICIOUS ACCOUNTS