Vulnerability Protection

Every now and then, a major security flaw is announced or even exploited on another significant website. This is unpleasant. If you care about the security of your web applications, Nette Framework is undoubtedly the best choice.

Cross-Site Scripting (XSS)

Cross-Site Scripting is a method of disrupting websites by exploiting unescaped outputs. An attacker can then inject their own code into the page, thereby modifying the page or even obtaining sensitive data about visitors. Protection against XSS requires consistent and correct escaping of all output strings. If your developer forgets this just once, the entire website could be compromised.

An example of an attack could be providing a user with a modified URL that injects code into the page. If the application doesn't properly escape outputs, the script executes in the user's browser. This way, for example, their identity can be stolen.

https://example.com/?search=<script>alert('Successful XSS attack.');</script>

Nette Framework introduces the revolutionary Context-Aware Escaping technology, which permanently eliminates the risk of Cross-Site Scripting. It automatically escapes all outputs based on the context, so a developer cannot accidentally forget anything. Example? A developer creates this template:

<p onclick="alert({$message})">{$message}</p>

<script>
document.title = {$message};
</script>

The {$message} notation means printing a variable. In other frameworks, it's necessary to explicitly escape each output, and even differently in each place. In Nette Framework, nothing needs to be escaped; everything is done automatically, correctly, and consistently. If we set the variable $message = 'Width 1/2"', the framework generates the following HTML code:

<p onclick="alert(&quot;Width 1\/2\&quot;&quot;)">Width 1/2&quot;</p>

<script>
document.title = "Width 1\/2\"";
</script>

Cross-Site Request Forgery (CSRF)

A Cross-Site Request Forgery attack involves the attacker luring a victim to a page that subtly executes a request in the victim's browser to a server where the victim is logged in. The server believes the request was made willingly by the victim. Thus, under the victim's identity, it performs an action without their knowledge. This could involve changing or deleting data, sending a message, etc.

Nette Framework automatically protects forms and signals in presenters against this type of attack by preventing them from being submitted or triggered from another domain. If you want to disable protection, use the following for forms:

$form->allowCrossOrigin();

or in the case of a signal, add the @crossOrigin annotation:

/**
 * @crossOrigin
 */
public function handleXyz()
{
}

In Nette Application 3.2, you can also use attributes:

use Nette\Application\Attributes\Requires;

#[Requires(sameOrigin: false)]
public function handleXyz()
{
}

URL Attack, Control Codes, Invalid UTF-8

Various terms related to an attacker's attempt to inject malicious input into your web application. The consequences can vary widely, from damaging XML outputs (e.g., non-functional RSS feeds) to obtaining sensitive information from the database or passwords. The defense is consistent byte-level validation of all inputs. And let's be honest, how many of you actually do this?

Nette Framework does it for you, automatically. You don't need to configure anything, and all inputs will be sanitized.

Session Hijacking, Session Stealing, Session Fixation

Several types of attacks are associated with session management. An attacker either steals or plants their session ID onto the user, thereby gaining access to the web application without knowing the user's password. They can then perform any action within the application without the user's knowledge. The defense lies in the proper configuration of the server and PHP.

Nette Framework configures PHP automatically. Thus, the programmer doesn't have to think about how to secure the session properly and can fully concentrate on developing the application. However, this requires the ini_set() function to be enabled.

SameSite Cookie

SameSite cookies provide a mechanism to recognize what led to the page load, which is crucial for security.

The SameSite flag can have three values: Lax, Strict, and None (the latter requires HTTPS). If a request for a page comes directly from the website, or the user opens the page by directly entering it in the address bar or clicking on a bookmark, the browser sends all cookies to the server (i.e., with flags Lax, Strict, and None). If a user clicks through to the website via a link from another website, cookies with the Lax and None flags are passed to the server. If the request originates in another way, such as submitting a POST form from another origin, loading inside an iframe, using JavaScript, etc., only cookies with the None flag are sent.

Nette defaults to sending all cookies with the Lax flag.