Application (Web,Mobile,Server) Security — How security gets compromised, How to take care of security, How to test & monitor your security provisioning

This article will be useful for hands on Application Developers/Architects/QA Engineers.

Typically, two places where vulnerabilities can exist in typical client-server application -

Client side

Web Application

Mobile Application

Server side


Files in Java Jars/Node Modules/Libraries/etc.

Batch jobs/shell scripts

Few more …

HTTP Request Model Vulnerabilities

Some amount of communication via HTTP is unavoidable for the majority of outward-facing web applications, making this a popular channel for attack. Malicious HTTP requests can be used to attempt a wide variety of attacks.

Components in web application subject to vulnerabilities or security attacks

Browser Cache (Browser Session Storage/Local Storage/etc.)

Web Cache aka Proxy Cache(e.g. CDN, web servers like Nginx/Apache/etc.)

HTTP Request Header

HTTP Request URL (e.g. /app/home/23)

HTTP Request Body (e.g. form-data)

HTTP Response Header

HTTP Response Body

There are certain types of vulnerabilities that exist when application exchanges data in XML format. Most of the modern applications are adopting JSON as an application data exchange format.So, I have excluded those vulnerabilities from the list.

I have added 3 categories —
How security gets compromised? (Referred henceforth as a CAUSE) How protection can be done?(Referred henceforth as a PREVENTION) How monitoring & testing can be done?(Referred henceforth as a VERIFICATION)


CAUSE: Client side (Web App →Browser Cache) :- Malicious HTTP requests XSS — Cross-Site Scripting, or XSS, is an attack that exploits holes in client-side security to inject malicious script into an application, which is then used to elevate privileges, steal session cookies, scrape page content, etc.

PREVENTION: XSS Attack Filtering.

Turn off HTTP TRACE support on all web servers.Approach mentioned below can help in Java

Spring Framework

Approach mentioned below can help in Angular & ReactJs can help

VERIFICATION: Please refer below urls


CAUSE: Client side (Web App →Browser Cache) :- Malicious HTTP requests

CSRF — Cross-Site Request Forgery, or CSRF, is an attack similar to XSS. However, rather than relying on a user’s trust for a site to gain access, these attacks exploit trust mechanisms used between two websites when exchanging information to inject code into privileged pages.

A classical example of that is when a user logs in, the website sends token information that is assigned to a cookie as part of the response. Now that the user has logged in, the attacker tries to make the user visit the attacker’s website from where the CSRF attack would start. To make the user visit his website, the attacker usually sends an email over email. If the user has clicked on that link, there are 1 or even more APIs on the website. A request is sent along with the cookie information which was sent earlier as a result of the user’s visit. Now the attacker is able to make unauthorised changes to the user’s data/account like transferring money for example.

PREVENTION: CSRF Attack Filtering.

Send hidden information as a part of the form submitted from the UI to have authenticity of the request.

Spring Framework

NodeJs+ExpressJs Application

VERIFICATION: Please refer below urls


CAUSE: Client side (Web App →Browser Cache) :-

Sensitive Data Exposure through Browser Cache
— Application Configurations

— System Ids (like User Ids)

— System Roles
If such information is available in browser cache in a non encrypted manner, then attackers can manipulate this information.

PREVENTION: Application configurations at client end should be in encrypted manner.

Instead of using System generated Ids, which are typically auto incremented (and easy to guess), you can generate

VERIFICATION: Please refer solutions mentioned in VERIFICATION #2


CAUSE: Client side (Web App →HTTP Request Body) :- Malicious HTTP requests

SQL Injection — this attack exploits applications that fail to properly filter user-generated SQL statements for string literal escape characters or which do not ‘strongly type’ user input. Escape characters, such as quotation marks or operators, when improperly filtered, can be used to change the function of a specific query to force disclosure of hidden information or erroneously validate a user. Fields that are not “strongly typed” (i.e., a field that requests a numeric variable but does not verify that the user input is numeric) can be exploited in a similar manner.

PREVENTION: Please refer below url to handle SQL Injection in Java & Spring .

NodeJs+ExpressJs, please use below mentioned plugin

VERIFICATION: Please refer solutions mentioned in VERIFICATION #2


CAUSE: Client side (Web App →HTTP Request URL) :- Using HTTP request smuggling to bypass front-end security controls.

In some applications, the front-end web server is used to implement some security controls, deciding whether to allow individual requests to be processed. Allowed requests are forwarded to the back-end server, where they are deemed to have passed through the front-end controls.

For example, suppose an application uses the front-end server to implement access control restrictions, only forwarding requests if the user is authorised to access the requested URL. The back-end server then honours every request without further checking. In this situation, an HTTP request smuggling vulnerability can be used to bypass the access controls, by smuggling a request to a restricted URL.

Suppose the current user is permitted to access /home but not /admin. They can bypass this restriction using the following request smuggling attack:

POST /home HTTP/1.1 Host: Content-Type:application/x-www-form-urlencoded Content-Length: 60 Transfer-Encoding: chunked

GET /admin HTTP/1.1 Host: Foo: xGET /home HTTP/1.1Host:

The front-end server sees two requests here, both for /home, and so the requests are forwarded to the back-end server. However, the back-end server sees one request for /home and one request for /admin. It assumes (as always) that the requests have passed through the front-end controls, and so grants access to the restricted URL.

PREVENTION: Server side validation should be in place to check access control for the user who is requesting a resource. Generate Security Token with Salt (like user id + user role).Spring example available below

NodeJs example available below

VERIFICATION: Please refer solutions mentioned in VERIFICATION #2


CAUSE: Client side (Web App →HTTP Request URL & Web App →HTTP Request Body) :- Guessable Data
— System generated sequential ids as a part of the HTTP Request URL or HTTP Request Body.

Attackers can manipulate such data with simple guesses to retrieve or manipulate other user’s data.

Spring Framework, please refer below url

Node, please refer below url

VERIFICATION: Please refer below URL


CAUSE: Client side (Web App →HTTP Request Body) :-
DoS or DDoS
User can repetitively do the action manually or through the program(e.g. Clicking multiple times on SignUp button)

PREVENTION: Use CAPTCHA in the frontend code.

Please refer below url

VERIFICATION:Tools like Selenium will help


CAUSE: Client side (Web App →HTTP Response Header) :-

HTTP Header Injection -

HTTP header injection is a general class of web application security vulnerability which occurs when Hypertext Transfer Protocol (HTTP) headers are dynamically generated based on user input.

Header injection in HTTP responses can allow for HTTP response splitting, Session fixation via the Set-Cookie header, cross-site scripting (XSS), and malicious redirect attacks via the location header.

More details available at this url

More about HTTP Response Splitting can be learned from this url

PREVENTION:Typically, It’s a bad idea to allow user input into the server response headers, but if it’s required then ensure that all carriage-return and line-feed characters (and all of their encoded variants) and appropriately filtered out to prevent attacks of this nature.

VERIFICATION: Please refer solutions mentioned in VERIFICATION #2


CAUSE: Client Side (Web App →HTTP Request Body) :- Malicious HTTP requests : OS Command Injection

Attackers identify a critical vulnerability in an application. This allows them to insert malicious code into the OS and gain any functionality the underlying application offers. The attackers can unleash the attack even without direct access to the OS.

The attacker alters dynamically generated content on a web page using HTML code through an input mechanism such as a form field or cookies.

Once the code is inserted into the affected web page, browsers interpret the code. This allows the attackers to execute specific commands across the user’s computers — along with both users’ networks and the infected system’s network.

Please refer this url for more details

PREVENTION: It’s vital to address potential vulnerabilities that could lead to an OS command injection attack. There are a few ways to handle the task:

Preventing manipulation at the source. It’s vital that any applications accessible through a web browser avoid user-controllable data in operating system commands. Development and cybersecurity teams should focus on the use of code that doesn’t allow for manipulation of server-level tasks via unintended commands.

Rejecting unacceptable code. If it’s impossible to find a safer and more secure way to perform server-level tasks, then it’s critical to strictly validate all user data. This is often achieved by creating a whitelist of acceptable values. In addition, some organisations limit input to short alphanumeric strings. Any input outside the range of acceptable data is automatically rejected by the system.

Controls over APIs. In some cases, an application might pass a command string for an API to a shell interpreter that handles command chaining and redirection. This can lead to a breach. Instead, the application should only launch a specific process based on a specific name and command line parameters. This way, even if attackers circumvent basic input validation methods, their options and choices are limited.

VERIFICATION: Please refer this url


CAUSE: Client Side (Web App →HTTP Request Body) :- Malicious HTTP requests : LDAP Injection (similar to SQL Injection)

LDAP injection is a type of attack on a web application where hackers place code in a user input field in an attempt to gain unauthorised access or information.An LDAP injection can lead to information theft, browser or session hijacking, defacement of website and worse.

Please refer this url for more details

PREVENTION: Preventing LDAP injection requires defensive programming, sophisticated input validation, dynamic checks and static source code analysis. Incoming data validation can clean client-supplied data of any characters or scripts that could possibly be malicious. Outgoing data validation validates all data returned to the user as an added layer of security. And LDAP configuration implements tight access control on the data in the LDAP directory.

VERIFICATION: Please refer solutions mentioned in VERIFICATION #9


CAUSE: Client Side: Sensitive data leakage through application screens (web/mobile screens) & through notifications like (email/sms).

PREVENTION: PII sensitive Data masking in application UI, notifications (email/sms/etc.).

VERIFICATION: Selenium Test cases will be helpful.


CAUSE: Server side: Trap Door
A Trap Door is when a designer or a programmer (or hacker) deliberately inserts a security hole that they can use later to access the system. A clever trap door could be inserted into a compiler, so that any programs compiled with that compiler would contain a security hole. This is especially dangerous, because inspection of the code being compiled would not reveal any problems.

i) Writing credentials into a logs ii) Storing Data backup to a location vulnerable from security perspective

PREVENTION: Monitor Server & Services log through central log management system. Regular scan/visit application configs/toggles/switches.

VERIFICATION: No direct way to test or monitor.


CAUSE: Server Side : Logic Bomb
A Logic Bomb is code that is not designed to cause havoc all the time, but only when a certain set of circumstances occurs, such as when a particular date or time is reached or some other noticeable event.

PREVENTION: Prevention is difficult in this scenario.

But few things can be done — i) regular scanning of deployed source code files. ii) regular analysis of traffic(inbound & outbound) for exceptional scenarios. iii) regular analysis of data patterns.

VERIFICATION: No direct way to test or monitor.


CAUSE: Server Side (Proxy Cache & HTTP Response Header). Cache Poisoning

If HTTP Response have been cached, and HTTP Header Injection can be exploited (as mentioned in point#), then attack can be magnified and impact a larger user base.

PREVENTION: Disable caching of confidential Resources at Web Cache (Proxy Cache) level. Below url will help, how to disable caching at web server level.

VERIFICATION: Please refer solutions mentioned in VERIFICATION #2


CAUSE: Server Side : Weaker encryption strategy. Attackers can easily decrypt the data which have been encrypted with Encryption Key smaller size (like 128 bits or 64 bits), by using automated programs. Data encrypted with weaker algorithms like Base64 is easy prey for attackers.

PREVENTION: Use strong encryption algorithms, specifically 256 bit. Use below link to refer stronger encryption key generation in Java

VERIFICATION: Please refer below urls


CAUSE: Server Side : Buffer Overflow

Coding errors are typically the cause of buffer overflow. Common application development mistakes that can lead to buffer overflow include failing to allocate large enough buffers and neglecting to check for overflow problems. These mistakes are especially problematic with C/C++, which does not have built-in protection against buffer overflows. Consequently, C/C++ applications are often targets of buffer overflow attacks.

Please refer this url for more detail.

PREVENTION: To prevent buffer overflow, developers of C/C++ applications should avoid standard library functions that are not bounds-checked, such as gets, scanf and strcpy.

In addition, secure development practices should include regular testing to detect and fix buffer overflows. The most reliable way to avoid or prevent buffer overflows is to use automatic protection at the language level. Another fix is bounds-checking enforced at run-time, which prevents buffer overrun by automatically checking that data written to a buffer is within acceptable boundaries.

VERIFICATION: Please refer solutions mentioned in VERIFICATION #9


CAUSE: Client Side & Server Side : HTTP Response Handling

Attackers always attempt to exploit vulnerabilities that exist in application tech stacks, open source libraries & popular 3rd party libraries. Not handling applications errors in the proper manner may result in Stack trace/Memory Dump/Heap Dump getting exposed to end users and application specific details will get exposed to the outside world.

Please refer this url for more details

PREVENTION: Regularly version upgrades to update security patches. Also, Application should ensure to hide the tech details

VERIFICATION: Please refer below urls


CAUSE: Mobile Side

ii) Improper Platform usage. Misuse of a device functionality or the instance of failure when using platform’s security controls. It can include platform permissions, Android intents, misuse of the TouchID, Keychain, etc.

ii) Insecure Data Storage. When someone gets access to a lost/stolen mobile device or when malware or another repackaged app starts acting on the adversary’s behalf and executes action on the mobile device. An insecure data storage vulnerability usually lead to these risks: Fraud/Identity Theft/Material Loss/Reputation Damage/External Policy Violation (PCI)

iii) Insecure Communication. When devising a mobile app, data is exchanged in client-server model. So, when the data is transmitted, it should first traverse the device’s carrier network and the internet. The threat agents could exploit vulnerabilities and intercept sensitive data while traveling across wire. Here are the different threat agents who exist: Adversary who shares your local network

— a compromised

— Wi-Fi Network or Carrier devices

— cell towers, proxy, routers, etc.

Malware on the mobile device.The interception of sensitive data via communication channel would end up in a privacy violation, which can lead to: Identity theft/Fraud/Reputational Damage.

iv) Insecure Authentication.The threat agents who exploit authentication vulnerabilities do so via automated attacks which makes use of custom-built or available tools. The business impact of this can be: Information Theft/Reputational Damage/Unauthorized Access to Data.

v) Insufficient Cryptography Risks. The threat agents in this case are the ones who have the physical access of data which was encrypted wrongly. Or where a malware is acting on the behalf of an adversary. Broken cryptography generally result in these cases: Information Theft/Intellectual Property Theft/Code Theft/Privacy Violations/Reputational Damage.

vi) Insecure Authorization Risks. In this case, the threat agents are able to access someone else’s application typically via automated attacks which use custom-built or available tools. It can lead to following issues: Information Theft/Reputational Damage/Fraud

vii) Poor Code Quality Risks. In these cases, untrusted inputs are passed by entities to method calls made in the mobile code. An effect of this can be technical issues which can lead to degradation of performance, heavy memory usage, and poor working front-end architecture.

viii) Code Tampering Risks. Usually, in this case, an attacker exploits code modification via malicious forms of the apps hosted in the third-party app stores. They might also trick users into installing an application through phishing attacks.

Please refer this url for more details

PREVENTION: Please refer this url for more detail

VERIFICATION: Please refer this url for more details

Links referred for the article

Web app & Server side

1) 2) 3) 4) 5) 6)

Mobile app side

1) 2) 3)

Phew. Too much things to take care of for secured application.

If you found this article useful, please clap. Also, you can leave your constructive comment below.

I am Chief Software Architect, working in Pune-India. I have 17+ years of experience in technology, and last 7+ years working as an Architect.