Skip to main content

Web Forms

Introduction​

Forms have multiple uses from search boxes to surveys, but arguably the biggest (in Digital Marketing) is lead generation. Hence there is particular interest in understanding the content a form is trying to receive, and from who… as it is often the starting of important customer engagement processes.

Do not forget that a form can be a two-way data exchange. We tend (in Digital Marketing) to expect a customer to complete a blank form. Yet, there are many cases where a form can be pre-filled such as for updating a profile, amending an order etc.

ORCA has the ability to search for web forms within the content of a page url. It does so by scanning the Lighthouse “Inputs” artifacts (lighthouse/types/artifacts.d.ts at 31bdd8ad2c0a9e2734fe230be0fbd7134296b8ed · GoogleChrome/lighthouse ). As a result we can Observe generic form attributes. From that we can Report on the Compliance to standards such as those define in this page through OCRAs ability to Audit a site. Hence this page also acts as the requirements input to the ORCA web form scanning process.

Finally a form, needs to be sound technically. This includes being secure, following HTML standards etc.

Note

For clarity

this page focuses on only webform presentation and submission of a webform’s content to an endpoint. The subsequent data handling etc. is not covered here, but must be correctly addressed.

this page serves as introductory guidance and does not, alone, aim to describe all requirements in detail

Form Standards​

The standard defined here, reflects an combination of inputs from Business, ORCA and Technical requirements, covering

  • the security of the form
  • the compliance of the form to applicable laws, standards, rules in accordance with local and global laws, Essity business standards etc. especially with respect to any sensitive data such as personal, financial.
  • compliance with Essity web standards
  • adherence to recognised web standards and best practices
  • appropriate lifecycle management of the form
  • effective review by ORCA (Observability, Reporting, Compliance and Audit)

The standards reflect a lot of overlap in the requirements from the areas above.

Finally the standards, and the approach to measuring adherence to those standards will evolve according to changes in the above.

Form Security Standards​

Essity​

At the Essity level, InfoSec standards must be followed. These can be found at https://sca.sharepoint.com/sites/TOI-InfoSec/SitePages/Standards.aspx. Whilst generic, many of these standards apply to web forms including:

  • Certificate
  • Information Classification
  • Information Exchange and Collaboration
  • IT Compliance
  • Privacy By Design
  • Software Development Life Cycle

National and International​

These standards often represent a minimum set of requirements and recommended best practices. In reality, it is challenging for the layman to be expert in all, but in general, they are broadly similar. Examples include

Furthermore, these are becoming more hierarchical, e.g. the local country law (Sweden), references the regional (EU), which references the global (ISO)

Web Form Specific​

The above standards are entirely applicable, but not specifically written for web forms. Hence it is important to consider web form specific security standards and practices. The following are the main considerations (but not excluding the above), applicable to add related parties (users, agencies, support etc.) and processes (search, lead generation, feedback, reporting etc.)

Forms should at least

  • ensure encrypted communication via a secure channel (TLS/HTTPS)
  • for sensitive data, ensure authentication
  • ensure measures are in place against spam, denial-of-service and other forms of malicious online activity
  • ensure all data exchange is filtered against malicious content (including form submission client and server side validation, data outside the form e.g. session or file data and any other attempt to transfer data via the form endpoints available)
  • ensure, as far as possible, usage only on secure devices (current browsers)
  • ensure all technical components (infrastructure, application code/packages) involved are regularly updated and scanned
  • ensure all access and administration by those acting on behalf of Essity follows Essity standards, with both technically and contractually enforced safeguards

It is important to highlight that webforms involve particular technologies with particular security considerations - including CSS and Javascript

  • both influence the presentation and user interaction of the form

  • can they be manipulated to trick the user to doing something vulnerable?

  • if 3rd party, do we have control over they use?

  • do they allow data to be leaked?

  • The same can be applied to any other CSS and JavaScript on the page - as any webform rendered on the page may be influenced by other components of the page

Failing to consider Security can leave webforms particularly vulnerable to attack, compared to normal web pages. Common attacks include:

  • Cross-scripting attacks. While cross-site scripting (XSS) can involve a variety of web applications, web forms are a common vector. Under this approach, it's possible to inject malicious scripts into application codes. If successful, these attacks can capture user keystrokes, obtain their cookie information, or send them to malicious websites.
  • SQL injection attacks. Structure query language (SQL) injections occur when spammers manipulate SQL code. This allows them to view, modify, or even delete data. This is a common approach to acquiring sensitive information. It's one of the internet's oldest attacks, and yet, it also remains one of the most dangerous.
  • Cross-site request forgery. If users are forced to complete unwanted actions on web forms or other applications, they may be unwittingly involved in cross-site request forgery (CSRF) attacks. Essentially, this approach involves tricking the user into performing unwanted actions on behalf of the attacker.
  • Customer data breaches. Several types of attacks can ultimately grant malicious users access to valuable customer data. Not only does this place customers at risk but it can also harm your reputation, making others think twice about interacting with your brand in the future.
warning

In short - web forms represent an increased security concern compared to regular HTML pages, and hence must be managed with this in mind. Indeed, it is strongly discouraged to deploy any webform without a security layer containing protection against DoS, WAF, bot etc. threats, which is actively managed.

There are multiple areas of compliance to be considered, at the local and regional jurisdiction levels, which are directly relevant to Essity Legal entities (companies etc.) operating in those jurisdictions

The following are the main considerations, but cannot be considered as the definitive list which continually evolves.

Data Privacy​

An ever-increasing array of data privacy laws govern how — and to what extent — web application security must be provided. Your need to comply with these laws may depend, in part, on where your business is based and how you operate.

As these regulations become more common, it’s important for website owners to adopt practices that facilitate compliant forms, regardless of geographic location. Currently, the most impactful data privacy laws include:

GDPR. Few privacy initiatives have proven as groundbreaking as the EU's General Data Protection Regulation. After taking effect in 2018, GDPR transformed how we perceive data privacy and consumer rights online. This legal framework mandates robust privacy protection practices, which extend to web form security.

CCPA & CPRA. Similar in many respects to GDPR, the California Consumer Privacy Act (CPPA) and its follow-up California Privacy Rights Act (CPRA or CCPA 2.0) provide clear guidance on business obligations regarding the collection of consumer information.

HIPAA. While it's been in effect for nearly three decades, the Health Insurance Portability and Accountability Act (HIPAA) continues to play a key role in determining how healthcare data is gathered and distributed. While web forms can make it easier to collect patient health information and share it with authorized parties, many are not actually HIPAA compliant. Violations can lead to major penalties.

and other countries and regions will have similar laws which are continually evolving e.g. Australia’s Privacy Act, Brazil’s Lei Geral de Proteção de Dados (LGPD) etc.

Accessibility​

Accessibility is an important aspect of design, but it also is an example of where lack of accessibility can be considered a barrier to usage, to the extent that it may provide sufficient basis for legal proceedings being launched against Essity. See Form Design Standards for the details on Accessibility.

For example, the European Accessibility Act (EAA, ref: EN 301 549) incorporated into the national laws of local EU markets, and the Americans with Disabilities Act (ADA). See more under Form Accessibility Standards below.

Content​

Like all content, forms are also subject to adherence to Essity guidelines on the avoidance of any form of offensive or malicious content being presented on the website.

Design​

Any web forms presented on Essity websites, needs to also provide appropriate reference to the websites “Terms and Conditions”, “Privacy” links etc.

If the form is embedded in an existing website page containing those, this is sufficient.

If the form is a standalone page, then corresponding design elements for the rest of the site should be applied including such mandatory links

If the form is a modal overlay, then it should be presented within the same context as the web page underneath

If the resulting submission, from the form presented, is sent to somewhere other than the website itself, this should be correctly described to the user as part of the “Terms and Conditions” and “Privacy” page content

warning

There should be no attempt to present a form experience on an Essity website, which is not actually managed by Essity. At best this is mis-leading. At worst, it can result in significant brand and legal damage

Explicit Acceptance and Opt-Ins​

In addition to the above which are based on implicit acceptance through browsing the website as per “Terms and Conditions”, “Privacy” links, there can be scenarios where it is deemed legally necessary to gather explicit acceptance from the user, usually as part of an overall form submission (often the checkbox style “I have read and accept “Terms and Conditions”, and “Privacy Policy” ☑️“).

Further similar agreements, often called Opt-Ins, may also be needed.

Form Design Standards​

Below are the various areas involved. Keep in mind, that in implementation multiple standards will apply even to the single element.

Form Visual Design Standards​

The visual design of the form needs to be implemented in accordance with several standards

  • accessibility (see below)

  • customer usability

  • brand compliance

Form Accessibility Standards​

Accessibility standards are an important requirements of webforms, for multiple reasons, even although we list them under design standards.

It is common for these standards to be quoted in legal mandates on accessibility. As Essity is an EU headquartered company operating in the EU, it is a good example to consider

Digital accessibility is a top priority for governments across Europe—in fact, it’s a legal mandate. Under EN 301 549, all public-sector organizations in Europe must ensure that their digital technology (including websites, software, electronic devices, and mobile apps) conforms with specific accessibility standards. Additionally, any businesses selling digital products into Europe’s public sector need to meet EN 301 549’s accessibility requirements. EN 301 549 has been adopted in all 28 European Union (EU) member states, three European Free Trade Association (EFTA) countries (Iceland, Norway, and Switzerland), and two EU candidate countries (Turkey and the former Yugoslav Republic of Macedonia). Public-sector organizations that fail to comply with this legislation may face fines or other legal penalties, while private-sector organizations limit procurement opportunities.

Furthermore

EN 301 549 defines technical requirements and currently includes the Web Content Accessibility Guidelines (WCAG) 2.1. However, the standard is slated to be updated as part of supporting the implementation of the EAA and is in the process of being updated to include WCAG 2.2. Because WCAG is an established framework for assessing digital accessibility in the EU, conforming to these criteria at an “AA” level (which includes A and AA criteria) is the best way for organizations to start ensuring they comply with the EAA. Additionally, EN 301 549 has other requirements for certain types of web content, software (such as mobile apps), and hardware that may apply.

Hence adhering to standards such as WCAG help to ensure legal compliance. The question is then, which standard is required in which jurisdiction by which point in time?

Essity web forms should comply with

  • Web Content Accessibility Guidelines (WCAG) 2.2 - Web Content Accessibility Guidelines (WCAG) 2.2

  • to “A” and “AA” levels

note

ORCA aims to support automatic scanning of web pages to WCAG 2.2 standard and report accordingly

See also

Customer Usability​

Accessibility drives much of the usability aspects of the form, but even without any accessibility considerations, good usability should be a the forefront of the form design. Accessibility will cover topics like tab order and colour contrast, but there are more considerations beyond direct accessibility including

  • clear, meaningful labelling of form fields e.g. “Date of Birth” and not “DoB”
  • correct types of form field, e.g. if you are expecting only a numeric value, do not allow text entries
  • ensure client-side form validation is user-friendly e.g. if there is an entry validation error, provide a meaningful error explanation next to the field rather than some cryptic error code next to the submit button
  • localise visual elements such as instructions, labels, buttons, error messages etc. (more on this later in the data schema and payload standards)
  • use multi-page (including answer based flow) forms logically in terms of questions per section/page etc.
  • show helpers where possible such as mandatory field indicators, progress indicator etc.

Form Technical Design Standards​

First of all, much of the technical design is as a consequence of adhering to the above standards. Yet, there are a multitude of technical choices which (at least directly) are somewhat independent from the above.

Starting with the basics, meaning understanding the HTML standards. See

note

Web forms are expected to be done using the normal POST method of with MIME type “application/x-www-form-urlencoded“

High-level Principles​

Forms are expected to use the standard POST method to a secure endpoint over HTTPS, with a MIME type “application/x-www-form-urlencoded“.

Forms supporting file upload (MIME type “multipart/form-data“) are permissible, subject to additional processing and safeguards to ensure binary file content is correctly handled in terms of security, privacy, data etc. standards (more on file data below)

Form submissions from the end client, directly to API endpoints are strongly discouraged. This approach introduces additional concerns of expected HTTP methods, required authentication between client and API endpoint, challenges in ensuring robust data validation etc.

Form Content Standards​

Form Data Schema Standards​

Mainly we consider a technical schema, but before that, consider the form purpose.

  • the form should collect relevant information, appropriate to the context / use of the form
    • a simple example is only ask for an email in a newsletter sign-up and not the postal address of the user (a clear example of adhering to good data privacy practices)
    • a form used for submitting complaints is almost certainly not the place to ask to be including a marketing newsletter sign-up (keeping the data collection to the direct need, and “spirit”/purpose of the form)

Now coming to the data schema itself. The schema is an embodiment of many of the above requirements.

The schema comes in two fundamental parts

  • the definition of the web form

  • the definition of the data handled by the web form

Form Definition Schema​

There are multiple considerations around the data used to defined the form. These are:

Areas​

The definition focuses on three areas

  • the metadata
    • the campaign metadata of the form
      • brand and campaign details at the regional and local market level
    • the channel metadata of the form
      • which channel is being used to deliver the form (e.g. brand site, Facebook etc)
    • the instance metadata of the form
      • who created it and when e.g. createdDate, createdById
      • the classification of the data e.g. personal
      • relevant business identifiers e.g. campaignId
      • the source/type/template metadata, as a form instance is often based on a template or similar
  • the presentation (UI) elements
    • name/title
    • description/explanation
    • formatting guidance e.g. sections, pagination
    • conditional logic guidance e.g. “if answered ‘yes’, jump to question 5”, “if ‘true’, allow edits”
  • the data elements
    • id
    • name
    • data type
    • data unit (days, kg, % etc.)
    • data constraints (between 0 and 100)
    • (if applicable) permitted list of values
    • data encoding e.g. base64, UTC
    • mandatory vs optional
    • read-only vs write

Visibility​

Then for each of these, there is the further differentiation of which of the above elements should be visible to the form user i.e. client-side in the html and which should not e.g.

  • creation details = hidden
  • campaignId = visible
  • campaignName = hidden
  • data classification = hidden
  • list of countries = visible
  • maximum order value = hidden (hidden client-side, but still used as part of server-side validation)

Localization​

Form labels, permitted list of values etc, need to consider supporting localization for the end user. Simplistically this is achieved by setting a common value, whilst allowing the name to be localized e.g. a man’s title (Mr) has a value of say 1 in all localized form, but appears in the “Title” dropdown list as “Mr” (en-GB), “Herr” (de-AT), “Snr” (es-MX) depending on the locale of the form.

The result is that a full webform definition has multiple inputs, and the consolidated definition of the form is often sourced/used across several systems.

To be clear - this defines the form - not the data the form is handling.

Form Data Schema​

The form data schema, naturally complements the form definition schema - but its focus is defining the form submission payload.

This payload definition has three aims:

  • to match the required data capture in business terms, including business validation

  • to guide the data validation in security terms (server-side validation)

  • to align to downstream system needs e.g. aligning to the standard CDC APIs for customer profile (Technical Documentation - Essity CDC Project - Confluence (atlassian.net))

Implementation​

At this point, we recognise we need

  • the definition of the webform
  • the definition of the data captured and submitted by the form

and then be able to generate a working implementation based on these definitions, looking something like

With some consideration, it becomes apparent that this is not trivial in practice - and a well considered approach to this generic need is required.

Form Schema Definitions​

With the above in mind, it is useful to provide meaningful examples. To this end, the following provides examples in JSON format - the prevalent data exchange format (txt/csv and xml formats are just about acceptable, but json is deemed by the industry overall, to be the most suitable and is reflected in its widespread adoption).

Start by considering the simple use case of an email newsletter sign-up campaign - see ORCA - Web Forms - Form Definition Schemas - 01. Newsletter Sign-up - where the user submits only “firstName” and “email”. It shows that there is actually a significant amount of baseline metadata required even for a minimal amount of user supplied data.

Then we can move onto more complex requirements.

File Based Data Submission​

Allowing the submission of file content is strongly discouraged without good reason, due to multiple concerns including

  • security including
    • malicious content e.g. malware
    • increased attack surface for the likes of DoS
  • unsuitable content
    • documents containing unsuitable text
    • images with unsuitable graphic content
    • unintentional receipt of sensitive information e.g. “proof of purchase” also includes sensitive banking details
  • effort to validate/moderate
    • AI can help, but human review is usually required

Should it be deemed valuable enough to support file based data submission, safeguards must be in place to address the above.