An overview of application security (AppSec)

A real life example

Before starting with this article, let’s put a real life example: Have you ever bungee jump? Depending on your answer Why and why not? Probably you did it for adventure, risk appetite or maybe you don't due to vertigo, or fear.

Image #1 Bungee Jumping
Image #2. Security in details

Do we write code that is secure?

Image #3. Feature / Security defects

Introduction to Application Security

Application security is highly related with security, so the main goal is to protect and preserve the confidentiality, integrity and availability of our data. This is called the CIA triad in all the books that you might read. But here are the details:

  • Confidentiality: Data is accessible only for the authorized users
  • Integrity: Data will remain unaltered by unauthorized parties during all the states of the data
  • Availability: Ensure that the information is always available by the authorized parties
Image #4. CIA Triad

Authentication & Authorization

Sometimes when talking about security there is a question that comes on mind is: Are authentication and authorization the same thing? Well, no. Authentication refers to who you are and authorization what you can do in a system. So there is not authorization without authentication in the beginning, this is important since in the OWASP TOP 10 from 2021 the Broken Access Control referred to this.


The STRIDE model was developed by Microsoft, and shows the different threads and how it affects the security property, For example, Spoofing identity affects the authentication since we are allowing an individual to pretend to be another person, therefore affecting Confidentiality as well of our CIA triad.

Image #5. STRIDE model of thread

Vulnerability & Exploits

If I ask for a real life example of what is a vulnerability and Exploit, what comes to your mind? Here is my example: Image that a farmer has a lot of cows, and he has been having issues with cows that are lost, he does not know if they are being robbed or killed by a predator during nights.

Image #6. Vulnerability & Exploits

OWASP top 10

This is the bible of all the security engineers working in application security,

Image #7 OWASP 2017 vs 2021

Broken Access Control

Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user’s limits. Common access control vulnerabilities include:

  • Violation of the principle of least privilege, where access should only be granted for particular capabilities, roles, or users, but is available to anyone.
  • Bypassing access control checks by modifying the URL (parameter tampering or force browsing).
  • Elevation of privilege. Acting as a user without being logged in or acting as an admin when logged in as a user.

Cryptographic Failures

This one leads to the exposure of sensitive data due to the failures in the implementation, the first thing is to determine the protection needed for the data in transit and at rest. For example, Credit card numbers and passwords, health records and if we are holding EU criticizing PII (personal Identifiable Information) may be under a regulation such as PCI DSS, HIPPA or GDPR.

  • Is any data transmitted in clear text?
  • Are any old or weak cryptographic algorithms or protocols used either by default or in older code?
  • Are default crypto keys in use, weak crypto keys generated or re-used, or is proper key management or rotation missing? Are crypto keys checked into source code repositories?
  • Is encryption not enforced, e.g., are any HTTP headers (browser) security directives or headers missing?

Zero Day Vulnerabilities

A zero day vulnerability is a vulnerability in a system or device that has been disclosed but is not yet patched, therefore the risk is critical since we cannot guarantee the uptime and security of our systems. An exploit that attacks a zero day vulnerability is called a zero day exploit. Some examples of zero day vulnerabilities are: HeartBleed, CloudBleed, Zerologon

Defensive Design Principles

There are 12 defensive design principles, each of them will help us to secure our applications while auditing, here is the list, we are going to review in detail a few of them:

  • Secure the weakest links
  • Defense in depth
  • Fail Secure
  • Grant least Privilege
  • Economize mechanism
  • Authenticate requests
  • Control access
  • Assume secrets not safe
  • Make security usable
  • Promote Privacy
  • Audit and monitor
  • Proportionality principle
  1. Secure the weakest links
Image #8. Securing the weakest link

2. Defense in depth

Defense in depth refers to not fall in only one security method, for example: Just an antivirus will not keep you safe for other more powerful malware, you may need more protection. That is why defense in depth is presented like an onion, in which we secure from the upper layers (end users) to the core business part (devices and servers)

Image #9. Defense in depth

Defense in depth vs Secure the weakest link

Can the defense in depth and the secure the weakest link be contradictory? The short answer is no, defense in depth add more redundancy in the security while the weakest link principle does not have overlapping functionality.

Fail secure & Fail Safe

Failure is unavoidable but it must be planed, because, What happens when our application crash? Are our security measures down? Is the data exposed in error messages? How our application behaves? These are some of the questions that we need to answer when developing apps, but all of them comes to a set of concepts called Fail Secure and Fail Safe.

Mitigating (some) Common vulnerabilities

When working in security we must apply the zero trust concept, in this case, if we send a request from the web browser, we should never trust the user input and perform the proper validations and also, if this front end validation is bypassed do a second validation at back-end to make sure we are also applying the defense in depth.

1. Input Validation

An input is anything that probably will be sent to our back end of our application and might reach the database, for example: If we have a quantity numeric input, we should not allow especial characters, words, we also must validate the type of input (integer, double,float) and ranges, min-max, length, etc. Following the quantity field example, what you consider that is wrong in this code?

Image #10. Input Validation

2. Regular Expressions (Evil Regex)

Some especial crafted regex can be used to cause a ReDos (Regex Denial of service) in our application, we can use SDL Regex Fuzzer from Microsoft to check if an specific regex is evil or not. Here is a good place to learn about ReDOS

3. File Uploading

Usually when a web application allows to upload files, there are several ways to identify which kind of patterns are allowed or not, this is a high security risk if not limited since can lead to LFI (you can learn more of it in my other article of Local File Inclusion) or RFI. So we must allow only the extension of the files that we want to handle and avoid the web server to read outside the target directory

4. Injection attacks

There are different types of injection: SQL Injection, XML Injection, OS Command Injection, LDAP Injection. Here we are going to take a look to the SQL injection.

5. Authentication

If an user is trying to access to our applications how are we going to allow them? Maybe with credentials (Username and password) if they are valid we continue if not, how many attempts are we going to allow? And in how many attempts are we going to show a captcha to avoid a brute force attack? What are the rules that we are going to use to store the password? Maybe a random salted password or also a 2FA?

6. Saving passwords

Passwords cannot be in plain text, there are different ways of securing passwords in our systems. One of them is using SALTED HASH PASSWORDS, which basically means to add a random generated value to the user password to create a completely different HASH, therefore making harder to the attackers to steal common passwords. Other way of doing it is to use not only hashing but also encryption.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Josué Carvajal

Josué Carvajal

Sr. Security software engineer working in the DevSecOps area. CompTIA Sec+, C|EH