Forem: Danilo César

Tired of Cookies? Here's the reason why

Danilo César — Sun, 15 May 2022 02:41:39 +0000

tl;dr: This post is an brief analysis about the issue of having so many "opt-in" banners about cookie consent policies, using mainly the GDPR as legal basis to this subject. Cookies are necessary to the technical proceedings and operations on many web servers, but it doesn't mean we don't get tired of ticking so many checkboxes online.

Introduction

You probably noticed that in the last few years most of sites are welcoming newcomers users with some kind of a banner, or a pop-up window, with a friendly message asking you to accept some cookies in order to access and enjoy the content of their pages.

There is a reason for it, and if you are the owner of some webpage that collects some user data, even if you are not sending it to third-party companies that generates analytics or user's behaviors reports, you should probably start doing it too. I know, it's frustrating, but it's necessary. Let's find out why.

Compliance and Accountability

The first thing we need to know about, in order to understand what those cookies mean, and why the companies are so worried about asking users to consent to this action, is due to compliance. In matter of legal aspects, it describes the needs to conform to the rules imposed to that subject or that proper area, and that also includes the law, standards and regulations.

Photo by Hassan Pasha on Unsplash

In matter of webpages, for instance, located in the European Union (EU), in the European Economic Area (EEA) or in the United Kingdom (whose state version, the UK-GDPR, is almost identical to the EU-GDPR), those owners of those pages must inform and obtain the authorization from the users whose data are being processed, whether for purposes of performance analysis, user experience metrics (UX) or even to target more relevant ads to the audience of their sites. This is what predicts the General Data Protection Regulation, or GDPR, one of the legal diplomas that disposes about privacy and personal data protection for people inside and outside those States.

💡 If you do not reside in the aforementioned countries, but does any operation involving processing of personal data from people or companies located in the countries where the GDPR rules applies, this law is also mandatory. This is what the Article 3(1) of GDPR disposes: "This Regulation applies to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not".

In fact, even if the website transfers these information to third-parties (who will process this data), those responsible for collect, organize and, finally, the processing of this personal data must ensure they do so within one of the disposed lawful basis.

And what are those lawful basis? The UK-GDPR predicts at least six of them:

By consent;
By contract;
By legal obligation;
For vital interests;
For public interest or legal authority;
For legitimate interests.

For the purposes of this article, we will solely focus on the first two of them: by consent; and by contract.

Image: Google 27 EU Locations Add Cookie Law Notice.

Lawful basis of GDPR

The lawful basis of contracts is usually associated with an agreement set by the parties, such as an employment contract or an obligation contracted by a company to store the personal data sent by the other party in order to process it, for example, to generate analytical reports used for decision-making.

Notice that when the law says personal data it does not mean just the full name, address, or telephone number of these data subjects. In fact, personal data means any information that can really identify that person. So, even if we are working with two different databases, where one of them contains the full name of a natural person, and the other one has the address associated with it, if we do an intersection of these two data sources, it allows us to identify this person. Therefore, both of them contains personal data.

On the other hand, the legal basis of consent is generally the easiest one to obtain, because the data subject (to whom the data relates) can state that agrees with the collect and processing of their personal data, and does authorize the website's owner to do so in order to fulfill specific purposes, unless it does not violates any law or misuses this information.

It means that these responsible for the website must be transparent, fair, and accurate at the time of collect. And if they want to transmit this data to third-parties, which GDPR refers to as data processors, they must also act in accordance with the law and with the purposes that the contract between the parties was established.

💡 If you are a developer and want to adapt to these rules, you must obtain the explicit consent of the data subjects before processing their personal information using cookies or any other third-party resources. Also, it is important to keep a log on when and how you obtained this consent, in a secure manner. You must also allow users to change their preferences later, revoking access to the information and deleting it.

For those reasons, we are often seeing alerts and requests to allow cookies in order to continue using the website. But, what if we don't accept cookies? And if we don't agree to our personal data to be collected, processed and used, even within purposes permitted by law, what do we do?

The answer is not simple.

Photo by Nicolás Varela on Unsplash

Why cookies?

It happens that, in many cases, those responsible for the sites - we will call them, from now on, data controllers, as GDPR did, but do not confuse them with data processors, the third-parties, ok? - allows the user to choose which cookies are used. In general, most sites display a list where the user can select and allow just the ones they deem convenient. However, not all cookies can always be denied.

💡 Although there is a few mentions on cookies in the GDPR and in the ePrivacy Directive, another regulation that conducts this mechanisms, both data governance regulations must be interpreted together. For the purposes of this article, we will focus on GDPR only.

Some cookies are vital to the website's functions, due to the nature of cookies: they store valuable information about the user's activity in the internet browser.

The reason for cookies - or, HTTP Cookies, the most appropriate technical term - is to allow webpages to store user's preferences and information while browsing. Cookies can temporarily save, as long as the duration of a session, for instance, user's login credentials for a social network, so it can prevent us to repeat the same step every time we click on a link or press F5 to refresh a page. Likewise, cookies may contain payment information for online shopping, responses to an electronic form, and other data.

💡 Why do we call it cookies? The term is a derivation of "magic cookies", a concept of Unix computing for transmitting information between the sender and the receiver.

Photo by Jon Tyson on Unsplash

For the purposes of this article, we will not cover the technical description on how cookies work. It is important, however, that you understand that cookies are important for storing user's session information, and work as "identification data" or "badge" on the server. Also, remember that cookies can contains personal and specific data about the user, and that's why that data controllers must implement good security practices in order to protect access and storage on their servers.

💡 There is a recent discussion about new alternatives to cookies, such as Federated Cohort Learning (FLoC), endorsed by Google, which aims to cluster people with relevant interests into large groups. FLoC has not been implemented for the general audience yet, but many people have already expressed concerns about this technology that will impact the advertising and digital marketing, for privacy reasons mainly. But this controversy is a subject for another post.

More cookies, fewer banners?

Now that we know what cookies are, and why they are necessary for websites, we can conclude that it is not easy for data controllers to choose to completely remove the banners and pop-ups windows that have been chasing us on almost all websites lately, calling for our attention in order to offer us some.

"Sharing is Caring", by Light Roast Comics.

Certainly, because data controllers must comply with specific laws and regulations, they cannot refrain from obtaining at least one of the lawful basis for processing users' personal data, but this does not mean that there are no other ways of doing it in a safe way, and also in accordance with GDPR, in compliance with the transparency and efficiency principles.

On the other hand, the option to avoid banners and consider consent to be implied, however, is not a valid option, according to the UK's Information Commissioner's Office: "your users must take a clear and positive action to consent to non-essential cookies". The same goes for pre-ticked checkboxes on non-essential cookies: "pre-ticked boxes or any equivalents, such as sliders defaulted to ‘on’, cannot be used for non-essential cookies". In order to obtain the user's consent for cookies considered non-essential for the server's workings, is required a "positive action" by the user, that must consent to the collect and processing data by clicking on an "Allow" button, or by checking a "Consent" checkbox.

Example of cookie notice on a website. In this case, the React Cookie Notice component.

If there are no other ways, after all, to obtain cookies, there are three possible options: (a) we can simply continue and accept it, which may displease the most concerned users about privacy and data protection; (b) suggest authorities to review and to regulate new rules on cookies and procedures for obtaining consent; or (c) seek less intrusive ways to obtaining consent and also the good practices in order to not negatively impact the user's experience.

Changes may come

In fact, criticisms on cookie consent policies have had an effect, and the European authorities have updated their guidelines on the interpretation of legal rules on this topic. However, the problem of thousands of pages displaying banners, pop-ups and their "cookie walls" still persists, and has raised questions even internationally.

The privacy and data protection policy is a right as well as an obligation, as it ensures greater transparency to data subjects, while imposing the need for accountability and compliance for both data controllers and data processors. Also, the new rules have caused the phenomenon of "opt-in fatigue", which we hope will be resolved soon.

Do you have any suggestion on how to solve the problem of so many opt-in on the webpages that we access? Don't you think it as a problem? Do you think there is something to be done on this way? Comment below your opinion or your suggestion about this subject. 📢

References

[1] Data protection under GDPR. (2021, March 26). Your Europe. https://europa.eu/youreurope/business/dealing-with-customers/data-protection/data-protection-gdpr/.

[2] Koch, R. (2019, May 9). Cookies, the GDPR, and the ePrivacy Directive. GDPR.EU. https://gdpr.eu/cookies/.

[3] Using HTTP cookies - HTTP | MDN. (2021, April 13). MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies.

Disclaimer: This article does contains some legal information for educational purposes only, but does not contain legal advice on any subject matter. If you need professional advice regarding your specific circumstances, please consult your attorney.

HTML Standards for Better SEO: The HEAD element

Danilo César — Tue, 06 Jul 2021 19:52:07 +0000

This article is also available in the following languages: Portuguese.

In this article, we will understand the basics of Search Engine Optimization (SEO), and of the HTML's format and syntax. We will also learn how to implement better tags on our websites, that can help us to reach better results on search engines, by investigating how they do work, and what are the meta tags that they understand.

💡 If you are not familiar with the HTML syntax, you should check my article “CSS and HTML Explained for Absolute Beginners: Part 1” before continue on this current one, as some markup language knowledge may be necessary.

Introduction

Suppose you are getting into a new author, and walk to the next bookstore, on your neighborhood, hoping that you will find this person's new book there. How do you start searching for it?

There are many options that may help you on this job: (a) you ask the salesperson, by giving some information about the book; (b) you walk through the aisles, looking for the specific category where the book belongs; or, (c) you look at every single book in this bookstore, one by one, looking for the specific cover that contains the information you're looking for.

“Shelf Bookcase Library”, by Deedee86 from Pixabay

As you can see, some of these choices may take a while, but they all have one thing in common: the document's metadata. It means there are some information on these objects that can be used for catalog, and also for better searching purposes.

This is the basic of Search Engine Optimization, or SEO techniques, a process meant to optimize the way we search for specific things on the internet. Let's investigate how this works, and how we can develop better implementations on our websites or applications, in order to reach better positions when users search for specific keywords on their favorite search engines.

What is SEO?

Search Engine Optimization (SEO) is a set of techniques in order to make the web content search-friendly, by making the search engines “understand” our website, and lead users to find us. The small improvements that we make, result in more relevant users viewing our content, and also help us to promote and monetize web content.

There are many experts on the internet that can help us to improve our visibility on those page's results, and also to provide useful services. Let's understand how we can apply some of these techniques by following the HTML standards.

“Search Engine Optimization”, by Gerd Altmann from Pixabay

How to insert meta tags in HTML

Before we get started, take a minute to check the metadata information used on this current webpage.

Above the web browser's address bar, the title, and the icon — a.k.a. favicon, the “favorite icon” — are presented even before the page is fully rendered. See how our web browser already collect some of this data? Under the hood, when a request is made to a web server, our web browser is looking for information like this:

<!doctype html>
<html lang="en" dir="ltr">
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <link rel="icon" href="/favicon.png">
[...]
    <title>My simple web page</title>
    <meta name="description" content="In order to fully understand SEO, we have to start by the basics, learning its fundamentals.">
[...]
  </head>

💡 Some browsers provide better information about the metadata gathered from the current webpage. If you're using Mozilla Firefox, you can open the Site Information panel by pressing Ctrl + I on your PC, or by following this guide. The opened window should look like this:

StackOverflow's homepage — yes, they do have a homepage! — seen in Firefox's Site Information panel.

Even if you don't fully understand HTML yet, notice these pieces of information:

The source-code tells the web browser that this is an HTML-type document;
The second line specifies that the following HTML elements are displayed in the English language, and the “left-to-right” (LTR) direction;
There are some viewport definitions for rendering the current webpage;
There are, also, some values provided for the icon, the title, and a description about this page.

HTML is not rocket science, so we can easily insert meta tags in our HTML file by adding it to the top of our content, inside the HTML's head element.

The head element is meant to provide some information about the page, such as rendering definitions, links, style-sheets, and scripts. Most of this metadata are not human-readable, and will not be displayed on the page, but will be only interpreted by the web server, and by the client's web browser.

The search engines usually collect data from the head element to provide better results, which means that we can insert meta tags to improve the visibility of our webpages and applications, like by following the HTML's formatting syntax.

HTML's formatting syntax

The HTML's formatting syntax is the set of rules that structure an HTML file, so its content can be recognized by the web browser and correctly rendered for the users' navigation.

There are many elements defined on the HTML Standards, and developers had also implemented non-standard elements and global attributes on their applications.

For the purposes of this article, we will cover only some of those that can be understood by SEO techniques, so you can implement it on your own website or application to achieve better results.

The document element 📃

The first step on creating an HTML file is actually informing that it is an HTML file.

According to the HTML Standard, by the Web Hypertext Application Technology Working Group (WHATWG), a community founded by the leading web browser vendors in 2004:

The html element represents the root of an HTML document.

In other words, it refers to the single element from where all the HTML's elements belong to. You can think it as node tree: the whole document is a document node; so other HTML elements are hierarchical nodes, like this:

The HTML DOM nodes structure. Image from W3Schools.

The document tree 🌳

The way most search engines work is by traveling relevant parts of the entire document, and then gathering information from its nodes, and creating relationships between the element and its content, such as texts, by looking for HTML's p elements (for the paragraphs), or images and its caption — like this one:

<figure>
    <img src="/media/cc0-images/elephant-660-480.jpg" alt="Elephant at sunset">
    <figcaption>An elephant at sunset</figcaption>
</figure>

Notice the alt attribute on the example above: it can be used by screen readers, for blind and visually impaired people, so they can know what this image is about; but also for SEO purposes, as we can describe for the search engine what this figure is about, and how it's related to near text.

Talking about web accessibility, we should avoid placing texts inside images, as it won't be read for many users. Instead, we can use a relevant image near a piece of text explaining what this is about.

💡 The best practice is to place the most important figure near the top of the webpage, like a banner image, and the other images near its context, such as the relevant text or section's heading.

The document metadata 📔

Another great way to provide information for the search engine is by using meta tags. In the HTML document, it can be provided right on the front matter, inside the head element. For example:

<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0">
    <meta name="generator" content="WordPress 5.6">
    <title>The document metadata</title>

    <meta name="author" content="John Doe">
    <meta name="description" content="This article explains the HTML metadata">
    <meta name="keywords" content="html,metadata,rfc">

    <link rel="alternate" type="application/atom+xml" href="blog-posts.xml">
    <link rel="canonical" href="http://www.example.com/html/">
    <link rel="license" href="https://creativecommons.org/licenses/by/4.0/">
</head>

💡 According to the HTML5 Standard, void elements, such as link and meta tags are self-closing, as they don't have any content. It means you can end them by just typing >, instead of />. Other void elements include: area, base, br, col, embed, hr, img, input, param, source, track, and wbr.

Let's understand each one of these elements used in our example code.

HTML head elements

The meta tag 🧬

First, the meta tag is used for defining metadata about the HTML file, and can modify the way web browsers render the document.

The MDN Web Docs has a great list about the values that can be assigned to the meta tag's name attribute, such as author, description, generator, and keywords. Most of them are self-descriptive, and automatically informed by modern frameworks already.

Let's revisit our previous example. The first three meta tags can be useful: (i) to inform the characters encoding — we're using UTF-8, the default charset —; (ii) to specify the device's size (also to enable the responsive behavior); and (iii) to identify the software that generated the webpage.

These three lines below can be used to describe the name of one of the page's authors, a brief summary of the document — modern web browsers may use it as the default description of bookmarked pages —, and some keywords (separated by comma) related to the current page's content:

<meta name="author" content="John Doe">
<meta name="description" content="This article explains the HTML metadata">
<meta name="keywords" content="html,metadata,rfc">

💡 Most of the search engines use this metadata to provide a short description of the webpage on their results, so using a good mix of keyword phrases can lead us to make better results. But be careful: numerous unnecessary keywords should be avoided, as they may harm your position.

If dealing with explicit content, it is strongly recommended by most of the search engines to specify the rating metadata, so it won't be included in the search results for users that are not allowed, don't want, or don't expect to find these, when using search filters, like Google's SafeSearch. It can be done by including one of the following meta tags:

<meta name="rating" content="adult" />
<meta name="rating" content="RTA-5042-1996-1400-1577-RTA" />

Another thing to notice about the meta tag is that many search engines may change the search result title if they notice an alternative text, inside the webpage's content, that better indicates their relevance to the users' query. According to Google Search Central, it occurs when “the title tag as specified by a website owner is limited to being static, fixed regardless of the query”, so the search result title might differ from the title tag defined in the HTML file.

The link tag ⛓️

Sometimes, developers need to establish connections to use external resources from a different location, for many reasons, such as to avoid repetition of code and patterns, so replacing it with another source also reduces the size of the single file. This can be done by using the link element.

The External Resource Link element, the HTML's <link> tag, tells the web browser to get this file, and use its content in the current web page. For example:

<link rel="icon" href="favicon.png">
<link href="default-stylesheet.css" rel="stylesheet">

<link href="https://example.com/css/print.css" rel="stylesheet" media="print">
<link href="mobile.css" rel="stylesheet" media="screen and (max-width: 576px)">

In this example, we are informing the browser to locate the default CSS file, used for most of the media types, in the default-stylesheet.css. Notice that files can also be located outside the current page's directory, as we are reaching the https://example.com/css/print.css file from a different web server.

The media attribute specifies that this resource should only be used by the web browser when the media condition is true. So, in our example, if we are trying to print this web page, our web browser will render the page according to the style-sheets located in that file.

For targeting printers, we can add our code inside the media breakpoint in our CSS file, like this:

@media print {
    .banner > p {
        background-color: #ffffff;
        color: #000000;
    }
}

💡 HTML respects the order of the information provided, so we can set a new CSS file to override the previous one: by adding an external resource link element after the default-stylesheet.css line, in our example.

The same applies to the mobile.css file: if we are opening this page on a device which screen is 576px or less, the browser will render the webpage according to its file.

💡 There are some common breakpoints, based on the general screen size ranges, such as: 576px (small devices), 768px (medium devices), 992px (large devices), and 1200px (extra-large devices).

“Responsive Web Design”, by Clovis Cheminot from Pixabay

For better SEO results, we should use the rel attribute as well, that can set a relationship between some linked resources and our current webpage.

According to MDN Web Docs, the rel attribute must express tokens that are semantically valid for both machines and humans. In our example, we already used three of them:

<link rel="alternate" type="application/atom+xml" href="blog-posts.xml">
<link rel="canonical" href="http://www.example.com/html/">
<link rel="license" href="https://creativecommons.org/licenses/by/4.0/">

Let's understand what does each one of them:

The alternate value describes other representations of the current document, such as a syndication feed, or an alternative format and language, intended for other media types. In our example, we are demonstrating that there is an Atom Feed for our blog-posts as an alternate representation.
The canonical value should be use if there is a single page that can be accessed on multiple URLs, or different pages containing the same content. It may occur when there are duplicate versions of the same page, such as example.com/html/ and example.com/?p=html, so all the other URLs with similar content will be considered duplicate URLs and crawled less often.

💡 Many developers usually post the same content on multiple blogging platform, or information channels, to engage a larger audience. This technique is known as “crossposting”, and should be used along with the canonical URL, so search engines can prioritize the one that is the most representative from a set of the duplicate pages.

The license value indicates the licensing information for the current element or webpage. It can be used on the <a>, <area>, <form>, or <link> HTML elements, and so provided a hyperlink with the rules and declarations, like this:

<a rel="license" href="http://creativecommons.org/licenses/by/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by/4.0/88x31.png" /></a><br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</a>.

💡 The synonym copyright is incorrect and must be avoided, although recognized by many web browsers and search engines.

The link tag, however, can't be used for loading scripts: instead, we can use the script tag.

The script tag 🕹️

The script tag is used for embed executable code, and is typically used to include JavaScript code. It can also contain data, such as JSON (JavaScript Object Notation), that can be processed in our web page or application.

As well as the link tags, script elements can refer to JavaScript code located in another web server or directory, like this example:

<script src="https://cdn.jsdelivr.net/npm/jquery@3.6.0/dist/jquery.min.js" integrity="sha256-/xUj+3OJU5yExlq6GSYGSHk7tPXikynS7ogEvDej/m4=" crossorigin="anonymous"></script>

Notice we are using the integrity and the crossorigin attributes when adding this request to an external web server. It is a good practice, in order to create more secure applications that the web browser check the response.

The integrity attribute prevents web browser to load content that doesn't match with the expected response from the web server. It contains a hash of a resource as its value, that ensures that the file was received unmodified and delivered without unexpected manipulation.
The crossorigin attribute defines how the element handles cross-origin requests, by adding an Origin field into the HTTP Request to a server from a different origin. It provides support for Cross-Origin Resource Sharing (CORS) mechanism, and can be set to either anonymous (default), or use-credentials values: the first one creates CORS requests with the credentials flag set to same-origin; the second one, with the credentials flag set to include.

In our example, the web browser won't execute the code if the delivered file doesn't match with the hash that was informed, using the SHA-256 cryptographic hash algorithm.

💡 HTML's link and script tags can implement the integrity and crossorigin in order to provide better security, by allowing proper verification of the received data and its source.

That code can be implemented in the head or in the body of our HTML file, so the web browser would request for the file before or after the page's content is fully loaded. Also, it can be loaded in parallel with the rendering of the webpage's elements, asynchronously, or synchronously.

Developers typically insert the script element right after all the elements of the webpage are defined: in general, this way you can ensure the user will not be presented to a blank page until all the scripts are loaded, what can take some time depending on the users' network.

💡 For the purposes of this article, we won't cover the pros and cons of inserting the script element on the head or the body element yet, nor doing it synchronously or asynchronously, as these topics require an article for themselves. In fact, you can follow this series as we will learn it in another time.

In SEO terms, placing the link and script tags inside the head or body element shouldn't matter, as search engine crawlers usually won't read scripts or style-sheets, rather than our HTML content. On the other hand, their placement may impact users' experience, and the order of their declarations matter to other scripts that use them as dependencies.

Conclusion

We're done, so let's recap. We covered the basics of SEO techniques, and how to insert meta tags using HTML. Then, we learned about the document's elements and tree. Finally, we covered a few HTML head elements, such as the meta, link, and script tags, and how to use it correctly in order to achieve better search engine results.

In the next article of this series, we will cover the HTML's body element, and how it can be implemented for better SEO results. Make sure to follow it. 🏆

Next steps 🚶

There are many protocols that enhances the power of SEO techniques, and we can apply them to our webpage, in order to make better results. If you'd like to know about them, make sure to follow this series, as we will continue exploring how to make use of better SEO techniques.

If you have any questions or suggestions about these subjects, please make a comment below. 📣

References 🧩

[1] The Document Metadata (Header) element - HTML: HyperText Markup Language | MDN. (2021, June 2). MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/head.

[2] The External Resource Link element - HTML: HyperText Markup Language | MDN. (2021, June 9). MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link.

[3] The metadata element - HTML: HyperText Markup Language | MDN. (2021, June 2). MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta.

[4] The Script element - HTML: HyperText Markup Language | MDN. (2021, June 2). MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script.

[5] Consolidate Duplicate URLs with Canonicals | Google Search Central. (n.d.). Google Developers. Retrieved July 5, 2021, from https://developers.google.com/search/docs/advanced/crawling/consolidate-duplicate-urls.

[6] HTML attribute: crossorigin - HTML: HyperText Markup Language | MDN. (2021, May 26). MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/crossorigin.

[7] HTML attribute: rel - HTML: HyperText Markup Language | MDN. (2021, June 22). MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel.

[8] HTML Standard. (2021). WHATWG. https://html.spec.whatwg.org/.

[9] SEO Starter Guide: The Basics | Google Search Central. (n.d.). Google Developers. Retrieved July 2, 2021, from https://developers.google.com/search/docs/beginner/seo-starter-guide.

CSS and HTML Explained for Absolute Beginners: Part 1

Danilo César — Fri, 18 Jun 2021 20:38:28 +0000

This article is also available in the following languages: Portuguese.

A few people have said in the past that the best way to learn something is by teaching others. So, here is my attempt to explain CSS and HTML languages in layperson terms, so absolute beginners can follow these steps in order to start a journey into the web development area. 🧑‍💻

In this article, we will be covering what does both CSS and HTML actually means, and how developers can build web pages using these languages. The logic behind it is similar to drawing. You wonder how? 🧑‍🎨

Introduction

You are probably a better artist than I am, but I am sure you at least once started a drawing like this: at first, you draw a head, a very well-known circle one; and then, made a stick body, with upper and lower members coming out of it.

Your drawing probably looked like this:

Image by Monika Zagrobelna on "How to Draw a Stick Figure: a Complex Guide"

So, how does it relate to CSS and HTML? I am glad you ask!

If you want a web browser to know the structure, in order to render a web page, you must present it a structure.

HTML, and the page structure 🏋️

So here comes the HyperText Markup Language (or its acronym, the HTML): it tells the web browser where the elements are located, and how do they exist.

💡 As you noticed, by its definition, HTML is a markup language, not a programming language. It does not use any variables or functions, so we can't make a full-functional application, nor interact directly with the elements on the page. To do this, we can use JavaScript or any other programming language.

By default, the most modern web browsers know how to render a paragraph, a button, or an input even if you don't tell them how it should appear. It's defined by the HTML Standard and by the vendor default CSS style-sheets in most browsers.

Actually, they don't look all the same on every web browser. So, there are some plugins that help developers by making it look “normalized”, such as normalize.css.

Also, in the HTML, we can make the web browser to behavior in certain ways, by importing a few “libraries” (that can help developers, as they contain many functions, so they don't have to write, or create, all that by themselves over and over again), and by containing some metadata, such as the title, the language, the viewport and the characters encoding standard (usually, developers use UTF-8, because it contains a lot of entities that we are used to reading in English).

Those libraries and metadata are too important in order to make the web browser render the page well, so we may want to load it before the web browser ends the rendering task. That's why we usually call it at the head, just before the browser knows what are the elements or how do they look.

The elements, right after the head being loaded, are located in the body structure. And they can be nested, just like branches on a tree.

So, that's the basic structure of the HTML, or the structure of a web page. A real-page may look like this:

<!DOCTYPE html>
<html lang="en-US">
    <head>
        <title>Here goes the Page's Title</title>
    </head>
    <body>
        <h1>This is a big heading</h1>
        <p>And this is a paragraph.</p>
    </body>
</html>

Notice how this markup language works: the elements, such as the title, the heading h1, and the paragraph (p) are expressed starting with <, and ending with />. Also, there are two elements “inside” the <html> one: the head, that contains the title element; and the body, where most of the elements are located, and displayed on web browser.

💡 Don't worry if you don't fully understand what this code does yet. We are just getting started, and if you reach this part, well done, you are really making progress! 👏

CSS, and the page look 💄

Now, let's go back to our drawing. We sure can make it look more elegant, funny, or even sexy. So, let's put some color into our character-friend.

We can change how do the elements, or how the whole page, looks, as we can put some colors and effects into our drawing. To illustrate that, we can turn our design into a completely different and professional look, like the “Unfinished Horse Drawing” that you are probably familiar with it:

“Unfinished Horse Drawing”, by Ali Bati, on Know Your Meme

That's the magic of the CSS, or the Cascading Style Sheets: it tells the web browser how these elements, and the web page's structure, should look, in order to make it successfully rendered.

By tweaking our CSS file — you can include it on the head, or on the body as well, in our HTML file, depending on when we want it to load by the browser —, the changes will apply whenever we open the page, or right after all the elements are rendered.

CSS can make changes to the structure as well. It can contain rules to create columns or rows for the elements to show, for example. Also, CSS can rule the elements' positions related to each other on the three-dimensional space(!).

You probably familiar with the X, Y and Z axis, right? In the CSS file, we can change the position and the scale of the elements, but also the z-index, that tells the order of the elements related to each other: elements with lower values are positioned backwards, and higher values, on the front, just like a 3D image.

A simple CSS file may look like this:

body {
    background-color: black;
}
h1 {
    color: blue;
    font-size: 32px;
}

The Cascading Style-Sheet syntax is different from the previous markup language: the elements are identified by their selector, such as the h1 there; then followed by a property and its value, like the color: blue; in our example; the declarations containing property and values are typed inside the { and } characters.

There are lots of great tutorials on how to create good-looking web pages, templates, and design trends for free on the internet — you can check it later, using the #web-development, #design and #css tags, for example.

Recap 🧩

We're done, so let's recap. We went through the basics on HTML, and learned about the head and body structure, that contains the elements and tell the browser how to render the page correctly. We also covered the basics on CSS, that is capable of changing the web page's look and feel, and how the elements appear before and after the page is successfully loaded.

Conclusion 🎉

The HTML5 and CSS3 (the current and latest versions of each one) can be used to create animations, patterns, and even interactive games. Browsers are also becoming much more smart, as developers are creating new tools and technical specifications in order to solve many problems nowadays.

The UI (User Interface) and the UX (User Experience) are crafting new ways to use those style-sheets and structures too, by making things beautiful and useful interfaces to us, the web users.

Next steps 🚶‍♂️

Now that we understand the basics on CSS and HTML, let me invite you to follow this series, so we can go even further on learning about web development. On the next article, we will be covering how to build a web page from scratch using these languages.

What do you think could be the next big thing developers may create on the upcoming new versions, like the HTML6 or CSS4? And, what kind of design do you want to achieve on the next steps? Tell us in the comments. 📢

References

[1] “CSS: Cascading Style Sheets”, from MDN Web Docs: https://developer.mozilla.org/en-US/docs/Web/CSS.

[2] “CSS Introduction”, from W3Schools: https://www.w3schools.com/css/css_intro.asp.

[3] “HTML: HyperText Markup Language”, from MDN Web Docs: https://developer.mozilla.org/en-US/docs/Web/HTML.

[4] “HTML Standard”, from WHATWG community: https://html.spec.whatwg.org/.

Understanding Cross-Site Request Forgery (CSRF or XSRF)

Danilo César — Wed, 09 Jun 2021 01:14:31 +0000

This post is also available in the following languages: Portuguese.

On the last article we have learned how we can prevent some Cross-Site Scripting (XSS) attacks by using proper sanitization techniques on our web server. Now, let's take a look at another vulnerability that also can cause problems on web pages that are not complying with the adequate security methods.

💡 If you did not read the previous article on this series, “Secure GET and POST requests using PHP”, I suggest you to do, as some knowledge on what are HTTP Requests, and how they do work, may be required in order to understand the following concepts — and, also, it can help you to increase your webpages' security.

Introduction

Let's investigate another one of the most common web vulnerabilities: the Cross-Site Request Forgery (CSRF), that tricks unwary users by making them execute unwanted actions on other web pages that they are already authenticated.

For a better illustration on the problem, let's suppose this scenario: you are logged in on your bank's account, which web server is not aware of best practices on web development; you noticed a strange transaction involving a person or a company you never heard about; on another browser's tab, you search for their name, and accessed their website. Now, even if you did not authenticate or connect to your bank's account into this unknown web page, and did not use a (secure) third-party challenge-response systems, our fictional malicious web page may already change your password, transferred your funds, or made a purchase using your credentials.

Sounds scary, right? Even that most modern browsers are committed to create “sandboxes” and limiting cookies' usage that are not on same-site's policy, there are many users on the world wide web using outdated web browsers, and clicking on every link that pops up on their monitors — most of them claiming that the user is a winner for entering the site on this specific date and time, or for completing a survey that they did not even hear about.

Tin can conversation. Designed by Wannapik.

In the past, some of the most accessed websites on the internet had suffered some sort of attacks related to CSRF, like Facebook, Netflix, Gmail, YouTube, and the New York Times, but also web applications, such as Mozilla Firefox and the Apache HTTP Server. According to this paper, many of them have already solved the problems, and others, thanks to the open developer community, fixed it as well.

By performing unwanted functions on legitimate user's session, those bad agents use their web links to initiate any arbitrary action they want on our website, which had already validated user's session cookie, and have it stored. That's the worst part on XSRF attack: it does not solely rely on the website's administrator behalf, it depends on how browsers work, and on users' behavior too.

How CSRF works

Let's revisit our example of the malicious page that performed an attack without the user's knowledge.

The first condition to the CSRF attack successfully works is a situation where the legitimate user is logged in on a trustful website, by keeping a session information such as HTTP Cookies, that also ensures shorthand verification of the users' credentials, so they don't need to inform their username and password on every request to the web server.

According to MDN Web Docs, HTTP Cookies are typically used to tell if two requests came from the same browser. Also, they remember stateful information for the stateless HTTP protocol, or encrypted HTTPS protocol.

The second condition is a request coming from a malicious website that makes the user's browser send a request to the web server where the user is previously authenticated, by doing a GET or POST request. It can be done, for example, by creating a web form, using HTML, whose target page is an unsecure web page on the trustful server.

In simple terms, the Cross-Site Request Forgery (CSRF) attack forges the request that is being sent to a trustful web server, so it is “crossing sites”. The following figure explains how does the CSRF attack work: the attacking site uses the users' authenticated session on the web browser in order to execute a trusted action on a trusted website.

Image: Souza, 2009.

For the purposes of this article, we will not cover this method on real-world applications, as our goal is not exploit any service, but, instead, to develop better implementations for the web.

Example #1: HTTP POST method

If the target page isn't CSRF-protected, those bad agents can successfully do whatever they want using the user's credentials. For example:

<html>
<body>
    <form id="evil-form" action="http://my.trustful.bank/transfer?amount=123&account=stevie" method="POST">
        <button type="submit">Click here</button>
    </form>
</body>
</html>

In this example, assume the page does really exist on the internet, and so the trustful.bank uses an HTTP request to send the amount of 123 dollars to a client identified as stevie, on the page /transfer-funds.

💡 This is not a good practice, so I am sure your (real) bank is secure, and protected against it. If they are not, like any other web server, the consequences would be devastating, and it may cause some legal issues, as they wouldn't be complying with most of the Data Privacy and Protection Regulations, such as GDPR 🇪🇺 and LGPD 🇧🇷, nowadays.

Example #2: Automatic behavior

Those bad agents don't even need the user directly interacting with the submit button in order to achieve the sending result. They could, for example, change it to an onload event that fires whenever the user's browser renders the page, like this:

<html>
<body onload="document.getElementById('evil-form').submit();">
    <form id="evil-form" action="http://my.trustful.bank/transfer" method="POST">
        <input type="hidden" name="account" value="stevie"></input>
        <input type="hidden" name="amount" value="123"></input>
        <button type="submit">Click here</button>
    </form>
</body>
</html>

Also, many web servers allow both HTTP GET and POST requests, so CSRF attacks could probably work on both of them.

Example #3: Without web forms

It goes even worse, as bad agents are not limited to the HTML web forms. They can use, for example, a simple img tag, like this:

<html>
<body>
    <img src="http://my.trustful.bank/transfer?amount=123&to=stevie" />
</body>
</html>

This attack can also force a user to follow a redirection, by inserting it on the httpd.conf or .htaccess file on their web server, like this examples taken from “XSS Attacks: Cross Site Scripting Exploits and Defense” (2007) book:

Redirect 302 /a.jpg https://somebank.com/transferfunds.asp?amnt=1000000&acct=123456

It would produce a request as the following one:

GET /a.jpg HTTP/1.0
Host: ha.ckers.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Accept: image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://somebank.com/board.asp?id=692381

And the following server response:

HTTP/1.1 302 Found
Date: Fri, 23 Mar 2007 18:22:07 GMT
Server: Apache
Location: https://somebank.com/transferfunds.asp?amnt=1000000&acct=123456
Content-Length: 251
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title></head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://somebank.com/transferfunds.asp?amnt=1000000&amp;acct=123456">here</a>.</p>
</body></html>

In this example, whenever the web browser performs the redirection, it will follow back to the informed location with the HTTP Cookies intact, but the referring URL may not change to the redirection page, what makes it even worse, because the user may not easily detect on referring *URL*s.

Who could imagine a single line could cause so much trouble, right? So, please remember: internet security is never too much, so there is always something new to learn and to apply.

CSRF and/or XSS attacks

The Cross-Site Scripting (XSS) and the Cross-Site Request Forgery (CSRF) attacks share some things in common, but they are not the same. Also, they can be used and implemented together.

An example of this combination was the “MySpace Worm” (also known as “Samy worm”, or “JS.Spacehero worm”), developed by Samy Kamkar, then a 19-year-old developer, in 2005, who created a script by adding a few words that infected some people's profiles to make him friends with, on this social network, but then quickly spread out of control, and he hit almost a million friend requests.

Part of Kamkar's MySpace profile showing how many friends he had after his script, on 2005. Image: VICE.

Although its attack was ultimately harmless, a bad agent could have injected malicious code that would compromised the whole web server, if no one had noticed or taken the threat seriously.

💡 The Cross-Site Request Forgery is also known as XSRF, as well as CSRF, following the acronym for Cross-Site Scripting (XSS). The probable reason for this one is to avoid the confusion with Cascading Style Sheets, used for stylize web pages, whose acronym is CSS too.

How to prevent CSRF attacks

So, how we can prevent CSRF attacks? There are some things we need to do:

1. Keep your web browsers up-to-date

You'd be surprised on how many users are still using outdated web browsers and applications on their daily basis. The reasons for it are uncountable, such as the lack of information (on how to do it, and why), the compatibility with a specific version (there are many situations where the retro-compatibility doesn't exist), or even the specifications of their contracts on their companies' behalf — and I am not talking just about web browsers.

As a user, the first measure to take is to keep your web browser updated to the latest version. The most used applications make use of WebKit, Gecko, or other browser engine, that has been currently developed and supported by the open community of developers. They are aware of these issues, and committed to solving these problems in a short term. Some of these companies behind major web browsers also have “bug bounty programs”, so they reward security researchers who can find a unique bug that may compromise user's data and privacy.

If you are a developer, you should alert your users that outdated application may cause some problems, including CSRF attacks, and they may be exposing their personal data to bad agents on the internet. As a bonus, this practice helps you to deliver better user experience, as updated browsers also include new functions and APIs that enhances the usability on many websites.

By the way, recently, Google and Mozilla have announced several improvements on the security of their browsers engines, such as the “privacy sandbox”, better HTTP Cookies policies, and JavaScript blocking mechanisms.

2. Check the HTTP Referrer header

Most requests on modern web browser include two metadata that can help us to validate where the source is: the Origin and the Referrer header information.

As a developer, you can check whenever a request is made to your web server if the Origin and Referrer header data came from the same site. If it does not, you can ignore it, and don't proceed any functions from this Origin.

Unfortunately, there are few situations that it won't be possible, and you may potentially block legitimate requests coming from users behind a corporate proxy or other similar features. Also, there are many ways to forge these headers' information, therefore many authors say it could be not the best way to protect web servers from CSRF attacks.

3. Implement SameSite attribute

The SameSite attribute (RFC6265bis) can really help us by mitigating CSRF attack, because an unauthorized website would not complete their request into our web server if they're using a cross-site request.

In order to make our HTTP Cookies restricted to the same-site location, we can implement this attribute by setting it to the HTTP response header. So, our HTTP Cookie can be restricted to a first-party or same-site context. For example:

Set-Cookie: TOKEN=1bf3dea9fbe265e40d3f9595f2239103; Path=/; SameSite=lax

According to the MDN Web Docs, the SameSite attribute can accept one of three values:

Lax — default if the SameSite attribute is not specified; HTTP Cookies can be sent when the user navigates to the cookie's origin site. They are not sent on normal cross-site subrequests (for example, to load images or frames into a third party site), but are sent when a user is navigating to the origin site (for example, when following a link).
None — HTTP Cookies will be sent in all contexts, and can be sent on both originating and cross-site requests. This should only be used in secure contexts, like when the Secure attribute is also set;
Strict — HTTP Cookies can be only to the same site as the one that originated it.

💡 If you're dealing with personal sensitive data, such as the ones used for users' authentication, on your web server, you should set a short lifetime for the HTTP Cookies. Also, you should set the SameSite attribute to Strict or Lax, so an unauthenticated request would not be effectively served to the web server.

Notice that you should use the SameSite attribute along with an anti-CSRF token, as some HTTP Requests, specially the GET, HEAD and POST methods, will be executed even if the request was not allowed, in some circumstances, and should return an HTTP error code in response. Anyway, a simple request was made and executed on the server-side. Fortunately, there are other ways to solve this, like using along with a random value generated by a complex and secure mathematical method.

4. Add random tokens

One of the most common methods of CSRF mitigation is by using an anti-CSRF token, a random, secret, and unique token sent on requests to the web server. Whenever the request is made, the web server could check for this data: if they match, then it is allowed to continue with the processing; if they not, then the request can be rejected.

This token can be generated for each request, stored on the web server, and then inserted on the client's request — directly on the web form, or attached to the HTTP request —, so it will be possible to detect requests from unauthorized locations to our web server.

The bad agents can't read the token, if used along with the SameSite attribute, and they can't proceed in any function on our website if they don't have the token matching to the one the web server previously set to this specific request.

This can be done by specifying an anti-CSRF token, on the same site as the trustful server, and including it to a new HTML web form, like the following one:

<html>
<body>
    <form id="good-form" action="http://my.trustful.bank/transfer" method="POST">
        <input type="hidden" name="token" value="1bf3dea9fbe265e40d3f9595f2239103"></input>
        <input type="text" name="account" value="stevie"></input>
        <input type="text" name="amount" value="123"></input>
        <button type="submit">Submit</button>
    </form>
</body>
</html>

On the client-side, we can set an anti-CSRF token in PHP, like this one:

<?php
$_SESSION['token'] = bin2hex(random_bytes(16)); // 1bf3dea9fbe265e40d3f9595f2239103
?>

Still on the client-side, if we are using JavaScript, we can add an anti-CSRF token, and send it as an X-Header information on a XMLHttpRequest. For example:

var token = readCookie(TOKEN);                       // Get the HTTP Cookie that we previously set, identified as "TOKEN"
httpRequest.setRequestHeader('X-CSRF-Token', token); // Then, send it as an "X-CSRF-Token" header information

Next steps 🚶

As mentioned before, internet security is never too much, so there is always something more to learn and apply. In order to build safer applications, be sure to follow the next article on this series, and read the further references to get more details about the best practices on web development.

If you have any questions or suggestions on how to build more secure applications, share it in the comments. 📣

References

[1] Zeller, W., & Felten, E. W. (2008). Cross-site request forgeries: Exploitation and prevention. Bericht, Princeton University. https://www.cs.memphis.edu/~kanyang/COMP4420/reading/csrf.pdf.

[2] Souza, J. (2009). Cross-Site Scripting & Cross-Site Request Forgery. Brasília, Universidade de Brasília. https://cic.unb.br/~rezende/trabs/johnny.pdf.

[3] Seth Fogie, Jeremiah Grossman, Robert Hansen, Anton Rager, and Petko D. Petkov. XSS Attacks: Cross Site Scripting Exploits and Defense. Syngress, 2007.

[4] "Cross-Site Request Forgeries and You", from Coding Horror: https://blog.codinghorror.com/cross-site-request-forgeries-and-you/.

[5] "Using HTTP cookies", from MDN Web Docs (Mozilla Developer Network): https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies.

[6] "CSRF", from MDN Web Docs (Mozilla Developer Network): https://developer.mozilla.org/en-US/docs/Glossary/CSRF.

Secure GET and POST requests using PHP

Danilo César — Thu, 20 May 2021 18:21:22 +0000

This post is also available in the following languages: Portuguese.

In this article, we will cover two request methods: the GET and the POST methods, for sending and receiving data from an HTML form using PHP. Also, we will examine the most common problems involving information security, such as Cross-Site Scripting (XSS) and SQL Injection, and how to solve them with adequate sanitization.

Let's start with the theory: what are GET and POST requests, and how do they differ? – if you want to, you can skip to the next section, where we will start with the practice.

**Understanding the GET and POST methods**

The Hypertext Transfer Protocol (HTTP) was developed as a protocol to serve the transmission of documents, and works as an intermediary between internet browsers and web servers. You are used to reading it in the addresses of web pages – as well as its “brother”, the HTTPS, a more secure encrypted version (hence the “S” at the end, meaning “Secure”).

In other words, HTTP is a protocol that serves as a “bridge”: it collects a request from the internet browser; sends it to the server; waits for an answer; and, finally, it returns the new information to the browser.

Generally, these requests keep some metadata in their “header”, that contains messages used to perform certain behavior on the client or on the server. In addition, HTTP requests can assume different models.

The most used HTTP request types are GET and POST, but there are other types in their technical specification, such as PUT, HEAD, DELETE, PATCH and OPTIONS. For the purposes of this article, we will focus only on the two most common.

**The GET request**

The GET request method is used when you want to obtain data from a specific source or resource. It should only be used to retrieval data, because its query string are sent and displayed at URL, for example: https://www.youtube.com/watch?v=fJ9rUzIMcZQ&t=3m5s.

When we insert this URL into the browser, we are asking the YouTube server for a specific resource: to retrieve the data from the video v identified as fJ9rUzIMcZQ. As soon as the server “returns” the request, the HTTP protocol will tell the browser how to display the video, in this example, the official video for the song “Bohemian Rhapsody”, by the British band Queen.

Note that in our example, the second parameter of the GET request, the t parameter, informs the start time that we expect in our response, in this case, from 3min and 5s. The parameters v and t are separated by the character &, which indicates to the HTTP protocol where the “key-value” pairs of these parameters begin and end. So, the server knows exactly that you search for the video v=fJ9rUzIMcZQ at the time t=3m5s.

GET requests are generally limited in length — for most browsers, it is up to 8 KB, or 8192 bytes in URI — and, because they only serve to request data, they are not able to modify it. In addition, they can be stored in cache, in the browser's history and also in the bookmarks. That's why you should never use it to send sensitive data, such as Social Security Numbers and user passwords.

💡 Some developers, however, ignore it and expose personal and sensitive data of people on the internet. In Brazil, due to the General Personal Data Protection Law (LGPD), this practice may cause big inconveniences, such as serious penalties to the company or to the ones who operate and manage this data, when a leak happens. So, the best practice is to never send sensitive personal data via the GET method.

**The POST request**

The POST request method is used to send data to the server, to update or create a new resource.

Unlike the GET method, the POST method does not expose the information at the URL address. In this case, the data is transmitted in the HTTP request body, as follows:

POST /update/webform.php HTTP/1.1
Host: youtube.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 42
user=Stevie&playlist=British&v=fJ9rUzIMcZQ

In this example, we are informing the Host: youtube.com server that we will make a POST method request to the /update/webform.php address, using the technical specifications of the HTTP/1.1 protocol. We are also indicating that there is a 42 character information (Content-Length: 42), in the standard Content-Type content format, whose value is application/x-www-form-urlencoded. Finally, our information is on the bottom line, containing 3 parameters: user, playlist, and v.

💡 The information traveling in the body of the HTTP request can be intercepted by bad agents. The best practice, then, is to make these transmissions using encryption, via the HTTPS protocol, so it makes harder to them read this information.

Let's assume the YouTube server recognized our request, and this address is valid. In our example, the informed video, which we received previously, will be added to the British playlist of the user identified as Stevie.

Note that this is a one-time request, which is unlikely to be repeated. As a rule, the POST method, unlike GET, is not stored in cache or in the client's browser history, nor can it be saved in bookmarks. POST requests have no restrictions on the size of messages, which allows us to send complete articles, such as this one, through an electronic HTML form, for example. Also, the POST method supports a wide variety of Content-Types, including binary documents, strings, and numbers.

💡 POST method is generally preferable over GET. However, there are situations in which we should include the requisition data in the address URL: for example, in search forms or by displaying documents and videos, because we want the client to be able to repeat it easily and to re-access the address through the browser's history.

Creating forms with HTML and PHP

Now that we understand how the GET and POST methods work in the theory, let's go to the practices: let's create an HTML form, and have it to send and to receive information using PHP.

💡 There are several ways to do this, like via JavaScript and AJAX, where the user don't have to refresh the page, because we are transmitting the information asynchronously. For the purposes of this article, we will focus only on HTML and PHP technologies.

Inserting the form on the page

The first step to create our web page is to inform the structure of the <form> element that will contain the fields where user types the data, like this:

<!-- origin.html -->
<form method="GET" id="webform" name="webform" action="target.php">
</form>

In this fragment, we are using the GET method, defined in method="GET", to send the information that will be inserted into the form, whose name was defined in name="webform", to the target page (action="target.php").

Inserting the fields to the form

The next step is to insert the fields, or inputs to our form, where users can type the values. Let's update our source file like this:

<!-- origin.html -->
<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>Electronic form</title>
</head>
<body>
    <form method="GET" id="webform" name="webform" action="target.php">
        <label for="iduser">User ID:</label>
        <input type="text" id="iduser" name="iduser"> <br />

        <label for="idplaylist">Playlist ID:</label>
        <input type="text" id="idplaylist" name="idplaylist"> <br />

        <label for="v">Video ID:</label>
        <input type="text" id="v" name="v" value="fJ9rUzIMcZQ"> <br />

        <button type="submit">Send data</button>
    </form>
</body>
</html>

We inserted 3 fields, defined by the HTML tag <input>, and also 1 button that sends the form's data, using <button type="submit">.

We also add labels to the text fields, using the <label> tags. Notice that each values on the for attributes, on each label element corresponds to an id attribute of one the input fields, like this: <label for="idplaylist"> refers specifically to the field that contains the corresponding id="idplaylist" attribute, and vice versa.

💡 It is possible to insert predefined values to the fields, adding the data corresponding to the value attribute in each HTML <input> element.

Finally, the name attribute in each <input> field will be used to obtain the values inserted by the user in the corresponding field when we move to PHP.

The final result, displayed in the client's browser, should look like this:

Reading data with PHP

After completing our HTML form, we can move on to the next step. Let's define the elements of the target page using PHP.

The source code below, inserted in the file target.php, will be executed by PHP as soon as the user submits the form data that we created earlier.

<!-- target.php -->
<?php
    // Prints the values of each field on the page
    echo(
    "The user identified as " . $_GET["iduser"] . " added the video whose ID is " . $_GET["v"] . " to the playlist " . $_GET["idplaylist"] . "."
    );
?>

Notice that we use the superglobal $_GET[] variable to obtain the values inserted by the user, that were transmitted using the HTTP protocol. For each <input> field that we previously created on the form, its corresponding name attribute must be informed within the superglobal variable. For example: the <input> field that shows the attribute name="iduser" can be found in PHP by using $_GET["iduser].

PHP has some native superglobals variables, such as $_GET, $_POST, and $_REQUEST. Remember that we use them according to the HTTP request method that we are using for data transmission, so it must correspond to what been defined in the method attribute of our <form> element.

💡 PHP's $_REQUEST superglobal variable can carry information from both $_GET and $_POST methods, in addition to any cookies transmitted in $_COOKIE. However, its use is not always recommended: the best practice is that developers know the methods used for inputs and outputs traveling on their server, in order to avoid more generic commands.

Then, we separate the strings and the variables in PHP with the . character, so each fragment of text is contained between the " characters, at the beginning and at the end of the sentence. Finally, we print on the user's screen the entire expression within the parentheses with the echo() function.

📝 Learn by doing

Did you notice that the URL address on target.php page shows the values typed in the source page?

Test #1: Rewrite the source code of the form we coded, using another requisition method, so that the information stays safe from reading by eavesdroppers and unauthorized people. After you finish, you can check the final answer.

Increasing HTML form security

Our HTML form is finally done! However, we can increase the security of our page, protecting the reading of the information on PHP.

This is our last step. We will add an extra layer of security, although basic, to prevent PHP from executing commands at the moment it receives and displays the values reported by the client.

💡 The rule in programming is to never blindly trust the values inserted by the user. Unfortunately, many bad agents have exploited technical problems on websites in order to collect sensitive information, or to damage servers by executing unexpected commands. For those reasons, it is very important that you protect, beforehand, the transmitted requests and the server, after all, if the users' interests are legitimate, they will also benefit from the increased security of your application.

The technique that filters and transforms the values entered by the user into simpler strings is called sanitization. By default, PHP has a collection of native functions that helps us on this step, such as the following:

htmlspecialchars() - Converts special characters, such as &“”<>, to HTML entities;
htmlentities() - Similar to the previous one, but it converts a larger number of characters to HTML entities;
strip_tags() - Removes HTML and PHP tags from a string, such as hyperlinks and comments.

When we use adequate sanitization, as soon as the server receives an improper information — for example, <script>alert('Intrusive alert');</script> — it will be transformed, “sanitized”, and should not display a warning message on the users' screen in this case.

💡 Notice that, in our example, we use a harmless, in theory, script — at most, uncomfortable for the user. However, it is important to reiterate: you must always protect and sanitize information. In other cases, a bad agent could transmit malicious scripts — this technique is known as Cross-Site Scripting, or XSS — or execute harmful commands to the database (usually called SQL Injection).

Let's edit the source code of our page, by adding one of these sanitizing functions. Our final code should look like this:

<!-- target.php -->
<?php
    // Prints the values of each field on the page
    echo(
    "The user identified as " . htmlspecialchars($_GET["iduser"], ENT_QUOTES, "UTF-8") . " added the video whose ID is " . htmlspecialchars($_GET["v"], ENT_QUOTES, "UTF-8") . " to the playlist " . htmlspecialchars($_GET["idplaylist"], ENT_QUOTES, "UTF-8") . "."
    );
?>

The final result, displayed in the browser, should look like the figure below:

📝 Learn by doing

Have you ever noticed that the majority of sites and search engines use the q parameter to transmit the data inserted by the user in the query requests to the server?

Test #2: Create a search form, using HTML and PHP, that contains at least 1 text field and 1 button to send the data, so that the address URL on the target page displays the q (or “query”) parameter. It should receive the values, sanitized, inserted by the user in the text field. After you finish, you can check the final answer.

Conclusion

So, we're done! We made our electronic form in HTML that is capable of transmitting data via HTTP request methods, in this case, GET or POST — and we also understand how they work —, and send them to the target page written in PHP. Then, it receives, handles the data, and displays the information on the user's screen. Also, we sanitized the values informed by the user in order to avoid serious problems of information security.

Next steps 🚶

Internet security it is never too much, so there is always something more to learn and apply. In order to build safer applications, be sure to follow the next article on this series, and read the Security topic in the PHP Manual.

If you have any questions or suggestions on how to build more secure applications using PHP, share it in the comments. 📣

References

[1] “HTTP Request Methods”, from w3schools: https://www.w3schools.com/tags/ref_httpmethods.asp.

[2] “HTTP”, from MDN Web Docs (Mozilla Developer Network): https://developer.mozilla.org/en-US/docs/Web/HTTP.

[3] “GET”, from MDN Web Docs (Mozilla Developer Network): https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET.

[4] “POST”, from MDN Web Docs (Mozilla Developer Network): https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/POST.

[5] “htmlspecialchars”, from PHP Manual: https://www.php.net/htmlspecialchars.

[6] “htmlentities”, from PHP Manual: https://www.php.net/htmlentities.

[7] “strip_tags”, from PHP Manual: https://www.php.net/strip_tags.

[8] “Superglobals”, from PHP Manual: https://www.php.net/manual/en/language.variables.superglobals.php.