Nino's Blog



Here are top 10 critical web app security risks according to OWASP organization:

1.) Injection

Anything that accepts parameters as input can potentially be vulnerable to a code injection attack.

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.

An injection of code happens when an attacker sends invalid data to the web application with the intention to make it do something different from what the application was designed/programmed to do. Perhaps the most common example around this security vulnerability is the SQL query consuming untrusted data, such as

String query = “SELECT * FROM accounts WHERE custID = ‘” + request.getParameter(“id”) + “’”;

Risk mitigation:

  • Input sanitization: Implement whitelisting approach at server side for what all can be accepted.
  • Use of safe API’s and parametrized queries.

2.) 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. Example:

  • Press the back button after logout to see if you can get into the previous session.
  • Try to hit the URL directly after logging out to check if you are able to access that page.
  • Check for the presence of session-related information in the URLs. Try manipulating them to check if you are able to ride someone else’s session.
  • Try finding the credentials in the source code. Right click on the page and hit view source. Sometimes coders hardcode the credentials for easy access which sometimes remain there unidentified.

Types of Vulnerabilities

  • 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 “knowledgebased 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.

Risk mitigation:

OWASP’s technical recommendations are the following:

  • 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 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. ID’s should also be securely stored and invalidated after logout, idle, and absolute timeouts.
  • Use of multifactor authentication

3.) Sensitive Data Exposure

Many web applications and APIs do not properly protect sensitive data, such as financial and healthcare. 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.

Risk mitigation:

  • Encrypt all data in transit (TLS) and at rest.
  • Use secure protocols and algorithms.
  • Disable caching of responses with sensitive data. Hackers might get the cached copies and steal the information from them.

4.) 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.

Risk mitigation:

  • Whenever possible, use less complex data formats such as JSON, and avoid serialization of sensitive data

5.) 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. In website security, access control means to put a limit on what sections or pages visitors can reach, depending on their needs. Example of access:

  • Access to a hosting control / administrative panel
  • Access to a server via FTP / SFTP / SSH
  • Access to a website’s administrative panel
  • Access to other applications on your server
  • Access to a database

Risk mitigation:

  • With the exception of public resources, deny by default.
  • Implement access control mechanisms once and reuse them throughout the application, including minimizing CORS usage.
  • The technical recommendations by OWASP to prevent broken access control are:

    • Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record. Note: For example, if a user log-ins as “John”, he could only create, read, update or delete records associated with the id of “John”. Never the data from other users.
    • 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). Note: We recommend our free plugin for WordPress websites, that you can download directly from the official WordPress repository.
    • Rate limit API and controller access to minimize the harm from automated attack tooling.
    • JWT tokens should be invalidated on the server after logout.
    • Developers and QA staff should include functional access control unit and integration tests.

6. 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 and upgraded in a timely fashion.


  • Directory listing available
  • Default error messages by the server can attackers getting to fingerprint the server abd version and launch targeted attacks.

Risk mitigation:

  • Have a hardening process in place for both hardware and applications. Do ensure that defaults are changed.
  • Install only the required features from a framework.
  • Review the security of the configurations at fixed intervals.

7. 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.

Cross Site Scripting (XSS) is a widespread vulnerability that affects many web applications. XSS attacks consist of injecting malicious client-side scripts into a website and using the website as a propagation method. The danger behind XSS is that it allows an attacker to inject content into a website and modify how it is displayed, forcing a victim’s browser to execute the code provided by the attacker while loading the page. XSS is present in about two-thirds of all applications. Generally, XSS vulnerabilities require some type of interaction by the user to be triggered, either via social engineering or via a visit to a specific page. If an XSS vulnerability is not patched, it can be very dangerous to any website.

Types of XSS:

Reflected XSS

  1. The application or API includes unvalidated and unescaped user input as part of HTML output. A successful attack can allow the attacker to execute arbitrary HTML and JavaScript in the victim’s browser.
  2. Typically the user will need to interact with some malicious link that points to an attacker-controlled page, such as malicious watering hole websites, advertisements, or similar.

Stored XSS

  1. The application or API stores unsanitized user input that is viewed at a later time by another user or an administrator. Stored XSS is often considered high or critical risk.


  1. JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS. Ideally, the application would not send attacker-controllable data to unsafe JavaScript APIs.
  2. Typical XSS attacks include session stealing, account takeover, MFA bypass, DOM-node replacement or defacement (such as Trojan login panels), attacks against the user’s browser such as malicious software downloads, keylogging, and other clientside attacks.

Risk mitigation

  • Output encoding and escaping untrusted characters.
  • Enabling Content-Security-policy (CSP)

8. 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.

Risk mitigation

The best way to protect your web application from this type of risk is not to accept serialized objects from untrusted sources. If you can’t do this, OWASP provides more technical recommendations that you (or your developers) can try to implement: • Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object creation or data tampering. • Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes. • Bypasses to this technique have been demonstrated, so reliance solely on this is not advisable. • Isolating and running code that deserializes in low privilege environments when possible. • Logging deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions. • Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize. • Monitoring deserialization, alerting if a user deserializes constantly

9. Using Components with Known Vulnerabilities

Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable 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.


  • Use of vulnerable PHP version
  • Out-dated kernel version – Linux
  • Unpatched windows
  • Vulnerable jQuery version

Risk mitigation:

  • Remove all unnecessary dependencies.
  • Have an inventory of all your components on the client-side and server-side.
  • Monitor sources like Common Vulnerabilities and Disclosures (CVE) and National Vulnerability Database (NVD) for vulnerabilities in the components.
  • Obtain components only from official sources.
  • Get rid of components not actively maintained.
  • Use virtual patching (rules that mitigate the specific vulnerability in software without changing the vulnerable code itself).s
  • Frequent patching process.
  • Subscribe to various forums which share the latest vulnerabilities and mitigation techniques/fixes.

10. Insufficient Logging & Monitoring

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack 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

Risk mitigation:

  • 24x7 monitoring of application traffic and log analysis.
  • Effective Security Incident and response procedures to be in place and practice.

Other OWASP security risks:

  • Clickjacking
  • Buffer overflow
  • Insecure API’s


Written by Nino Majder who lives and breaths web development. Follow him on Twitter