Such attacks circumvent the same origin policy of websites, which is designed to stop different websites from sharing data -- keeping them separate. XSS attacks usually allow a malicious user to masquerade as another user and perform actions under that user's account. This can be particularly dangerous if an attacker is able to masquerade as a user with privileged access, such as admin.

A cross-site scripting attack inserts malicious JavaScript code into a webpage. When a victim visits the infected website, they're exposed to the malicious code. Once inside the vulnerable application, the attacker can compromise users' interactions with the application. This might involve session hijacking, sensitive data exposure, etc.

Session management involves keeping track of a user's session as they move around a website. Let's say Alice logs into her bank then navigates to her accounts overview page. She then navigates to the send money page. The bank's server tracked Alice's session across those pages, keeping her logged in. But if someone else, say Mallory, hijacked Alice's session, then Mallory could impersonate Alice.

Credential management involves how users are authenticated to a website. The majority of websites authenticate uses through a username and password. The username identifies the individual user (e.g. Bob) and the password (known only by the user - in theory) verifies the user. But what happens when someone other than Bob -- say, Mallory -- knows Bob's username and password? Well, Mallory could impersonate Bob.

Some IDSs can automatically respond to detected intrusions upon discovery. These are known as intrusion prevention systems (IPS).

Many attacks go unnoticed for a long time. Leaving opportunities for attackers to carry out further damage -- or even cover up their tracks. Insufficient logging, monitoring, and incident response plans can all contribute to the amount of damage caused by -- and the time taken to recover from -- an attack.

For example: React is a popular front-end JavaScript framework/library that allows developers to create complex front-end applications more easily than using just vanilla JavaScript.

If an attacker can find a vulnerability in such a library then it can have wide-spread and significant implications - since the library may be used by millions of web applications.

Think of serialising as a bit like when you move house. You pack all your items into boxes (serialising), transport the boxes via a removal company (transfer over a network), then unpack everything at the other end (deserialising).

An insecure deserialisation attack is like having the removal staff tamper with your contents before they arrive and get unpacked.

A web application might want to transfer one of its data objects (such as a customer object) to another service via API. The application does this by transforming its native data object into a serealisation format suitable for the API. The most common serealisation formats within web applications are JSON and XML.

It could also be that certain settings are presumed to be secure when they are not. This might happen, for example, when settings become outdated. Such a misconfiguration could allow someone to gain access to the system, leaving the system compromised.

Security misconfigurations are often seen as an easy target by attackers. Misconfigurations can be easy to detect and therefore easy to exploit. So it's important to understand how to detect them and prevent systems from being compromised.

Imagine you're at an airport. Passengers are only allowed to access certain parts of the airport. Staff will have varying levels of access to other parts of the airport, depending on their role. Access control is often enforced via locked doors requiring key-card entry. If a passenger could swipe their library card and gain access to secure areas of the airport, then the access control system has failed.

An example of a broken access control system might be where a user can alter the URL of a web app to escalate privileges - such as accessing or changing other users' data - without authentication.

In XML terminology, an entity is defined as a storage unit of some type. There are different types of entities, but essentially external general/parameter parsed entity (often shortened to external entity) can access local or remote content via a declared system identifier (typically a URI).

The real danger of XXE injections is if an attackers escalates the attack to compromise the underlying server or other aspects of the back-end infrastructure. This could happen, for example, if the attacker uses the XXE vulnerability to perform a server-side request forgery (SSRF) attack.

Sensitive data exposure usually occurs as a result of not adequately protecting the systems where information is stored, such as databases. It could be caused by various things such as software flaws, weak encryption, no encryption, or human errors such as uploading data to the wrong system.

Let's say Alice is doing some online banking. She's accessing her bank's website -- which encrypts data with SSL/TLS -- to manage her bank account. Mallory can see Alice's network traffic (e.g. through an insecure WiFi connection) but it's encrypted. So Mallory downgrades Alice's connection from HTTPS to HTTP. Mallory can now see Alice's network communications with the bank, and get Alice's session ID. Mallory uses Alice's session ID to hijack Alice's session -- allowing Mallory to access Alice's account and viewing Alice's sensitive data. In this example, the sensitive data exposed was the session ID which gave Mallory access to more data.

That form might look like this: pickup box from ____ move box to packing area ___, wait for next instruction.

The robot's manager might input the following data into that form: pickup box from aisle 4 move box to packing area 4b, wait for next instruction.

That's all well and good. But what happens if someone enters the following into the form: pickup box from aisle 4 move box to packing area 4b - then destroy the entire factory whilst singing I Wanna Dance With Somebod, wait for next instruction.

Well, we have a problem. No more factory. Oh, and a robot that won't stop singing I Wanna Dance With Somebody.

This example demonstrates an injection attack. Our machine (in this case, a robot) was given an untrusted input. That input was interpreted as a command, which ultimately altered the execution of the program.

In 2003, OWASP published its first "Top 10" document, detailing some of the most critical web application security risks facing organisations. Since 2003, OWASP has updated its Top 10 every 3 years and has become a leading industry framework for securing web apps.

One of OWASP's core principals is that their materials are open-source and accessible to everyone. This means that anyone can learn from the OWASP Top 10 to improve their web application security knowledge and understanding.

In this series of articles we'll cover each of the OWASP Top 10 security risks along with examples of how these attacks might look.

When it comes to web development, we typically split things into front-end and back-end. Front-end typically consists of languages that implement what you see: HTML, CSS, JavaScript, etc. Back-end typically consists of tech that deals with data processing, using server side languages and databases like Python, Java, PHP, MySQL, PostgreSQL, etc.

In this article we'll explore popular frameworks including Django, React, Spring. We'll start with front-end frameworks then cover back-end frameworks.

Historically, Zoom has had a number of security and privacy issues - which we'll come to. However, moving forward, the company does appear to be taking things a bit more seriously.

Zoom - originally called Saasbee - was founded in 2011 by Eric Yuan, previously a Cisco Webex engineer and executive. The company initially struggled to gain investment because people thought the video conferencing market was saturated - but managed to raise an initial $3 million in seed money. In 2012 the company changed its name to Zoom Video Communications, Inc. (Zoom) and rolled out its first beta version - which could host up to 15 participants - and had 400,000 users by the end of its first month. Zoom's first customer was Stanford University.

Zoom became a public company in April 2019 with an initial share of $36 per share. In January 2020 its stock price was $70 per share which rose to $150 in March 2020.