Skip to main content
Engineering LibreTexts

11.6 Deployed Applications and Web Applications

  • Page ID
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

    ( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\id}{\mathrm{id}}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\kernel}{\mathrm{null}\,}\)

    \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\)

    \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\)

    \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)


    Software security does not stop at the time the software is shipped! Particularly in cases where the software is a web application and the software is used constantly by users all over the world. Additionally, web applications are accessible from nearly anyone in the world, making them a target for attacks.

    This chapter focuses on software as it is being designed and developed, but a quick look into the last 3 of the OWASP Top 10 rounds out the chapter.

    A05:2021-Security Misconfiguration

    Misconfigured software happens frequently; most of the time the consequences are not large but sometimes sensitive data may be leaked.

    Stack Traces

    A "stack trace" describes where in the code an error occurred. So called "stack traces" are helpful when developing code and debugging failures. However, stack trace data can sometimes contain sensitive or proprietary information. As such, a stack trace should never be displayed to a user. The image below indicates an actual stack trace from a web application.

    The image shows the message: "An unhandled error has occurred in the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code

    Figure \(\PageIndex{1}\): Server Error in web application (CC-BY-SA)

    Note that the stack trace suggests some very useful information for a hacker. In particular, consider:

    • A fully qualified directory name exists - this might be useful for a path traversal attack

    • The "GetSiteByDomain(servername)" function suggests that perhaps other sites use this software; maybe an nslookup or whois would lead to other sites which can be compromised

    Be sure to look at the OWASP45 page for more details.

    A09:2021–Security Logging and Monitoring Failures

    This refers to two separate but related concepts:

    • Security Logging - persisting an audit trail such that details of how a breach occurred are available after the fact in order to provide evidence

    • Monitoring - observing user behavior, often by referencing logs and audit trails, in real time or close to real time

    Security logging is useful in order to keep a record of what is happening at any point in time within the system. Logging alone will not prevent an attack, but it will make it easier to figure out what happened.

    Conversely, monitoring the system (and often the security logs) is a way to identify attacks in real time or discover that an attack occurred after the fact. With the rise of artificial intelligence or machine learning, coupled with the sharp rise in cyber attacks and ransomware attacks, real time monitoring is becoming a big market for software vendors.

    Be sure to look at the OWASP page46 for more details.

    A10:2021–Server-Side Request Forgery (SSRF)

    Rounding out the OWASP Top 10 is server side request forgery47. As web browsers become more advanced and security aware, SSRF attacks are not as commonplace as they once were.

    Bank Example

    To better understand this scenario, follow this example:

    1. A user logs into their online bank using a web browser

    2. The user does not log out, but navigates to a malicious page

    3. The malicious page can, behind the scenes, send a request to the users bank in order to transfer money from the users account into the attackers bank account

    This happens because the attacker is able to take advantage of the way web browsers work. In particular, any cookie associated with a website is sent with each request to that site. Additionally, session information is often stored in a cookie. That means that any request from a web browser to a specific web site will result in the cookie being sent, regardless of who told the browser to send the request. All the attacker needs to do is:

    1. Hope that a user is logged into a bank website (

    2. Convince the user to visit the a malicious site (

    3. The malicious site can use JavaScript in order to send a request from the user's browser to the user's bank website ( in order to transfer funds

    From the bank website's perspective, nothing is amiss as the user has valid cookies and valid session information. From the user's perspective, there is no visual indicator that any attack happened and the attack will go unnoticed until the user checks their balance at some point later.

    Server-Side Request Forgery is a collection of techniques to prevent attacks of this nature. Mitigation tactics can be found on the OWASP page48 for this vulnerability.

    1. A05:2021 – Security Misconfiguration
    2. A09:2021 – Security Logging and Monitoring Failures
    3. A10:2021 – Server-Side Request Forgery (SSRF)
    4. A10:2021 – Server-Side Request Forgery (SSRF)

    11.6 Deployed Applications and Web Applications is shared under a not declared license and was authored, remixed, and/or curated by LibreTexts.

    • Was this article helpful?