Forms, Security & Safe HTML

Forms, Security & Safe HTML

HTML forms collect information from users, but accepting user input also introduces important security, privacy and validation concerns.

A professional web application should treat all data received from a browser as untrusted input.

1. Building a Safe HTML Form

A basic form should have a meaningful action, an appropriate HTTP method, labels for controls, and suitable input types.

<form action="/register" method="post">

    <label for="name">
        Full Name
    </label>

    <input
        id="name"
        name="name"
        type="text"
        required>

    <label for="email">
        Email Address
    </label>

    <input
        id="email"
        name="email"
        type="email"
        required>

    <button type="submit">
        Register
    </button>

</form>

2. GET vs POST

The method attribute determines how form data is submitted to the server.

GET Example

<form action="/search" method="get">

    <label for="query">
        Search
    </label>

    <input
        id="query"
        name="q"
        type="search">

    <button type="submit">
        Search
    </button>

</form>

POST Example

<form action="/account" method="post">

    <label for="display-name">
        Display Name
    </label>

    <input
        id="display-name"
        name="display_name"
        type="text">

    <button type="submit">
        Save
    </button>

</form>

3. Always Protect Sensitive Form Transmission

Forms containing passwords, personal information, payment information or other sensitive data should be submitted over HTTPS.

<form
    action="https://example.com/login"
    method="post">

    ...

</form>

4. Handle Password Fields Correctly

Use type="password" for password entry.

<label for="password">
    Password
</label>

<input
    id="password"
    name="password"
    type="password"
    autocomplete="current-password"
    required>

For account registration, an appropriate autocomplete value can indicate that the field expects a new password.

<input
    id="password"
    name="password"
    type="password"
    autocomplete="new-password"
    required>

5. HTML Client-Side Validation

HTML provides built-in validation attributes that can improve the user experience.

<input
    type="email"
    name="email"
    required>

<input
    type="number"
    name="age"
    min="13"
    max="100"
    required>

<input
    type="text"
    name="username"
    minlength="3"
    maxlength="30"
    required>

Common HTML validation attributes include:

6. Client-Side Validation Is Not Enough

Browser validation can be bypassed. A malicious user can disable JavaScript, modify requests, use browser developer tools or send requests directly to the server.

Example

Suppose an HTML form specifies:

<input
    type="number"
    name="age"
    min="18"
    max="100"
    required>

The server must still verify that the submitted value is actually acceptable.

7. Treat All User Input as Untrusted

Data can arrive through more than visible form fields.

• Form fields
• URL parameters
• HTTP headers
• Cookies
• Uploaded files
• API requests
• Browser storage

8. Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) occurs when untrusted data is inserted into a webpage in a way that allows unintended script execution in a user's browser.

Unsafe Concept

<div>

    <!-- Never blindly insert untrusted HTML here -->

</div>

If an application accepts user-generated content, it must safely handle that content before displaying it.

9. Output Encoding

Data should be encoded appropriately when inserted into an output context.

For example, user input displayed as ordinary HTML text should not automatically be interpreted as HTML markup.

10. SQL Injection and HTML Forms

HTML forms themselves do not cause SQL injection. The problem occurs when server-side code constructs database queries unsafely using untrusted input.

For example, a login form may submit:

<input
    name="username"
    type="text">

The server must never blindly concatenate that value into an SQL statement.

11. Cross-Site Request Forgery (CSRF)

CSRF is an attack in which a victim's authenticated browser is tricked into sending an unintended request to a website.

State-changing operations should be protected by appropriate server-side controls, such as CSRF tokens where applicable.

12. CSRF Protection Concept

A server can generate a unique unpredictable token associated with the user's session and require that token with state-changing requests.

<form action="/profile/update" method="post">

    <input
        type="hidden"
        name="csrf_token"
        value="SERVER_GENERATED_TOKEN">

    <label for="display-name">
        Display Name
    </label>

    <input
        id="display-name"
        name="display_name"
        type="text">

    <button type="submit">
        Save
    </button>

</form>

The server must independently verify the token. A hidden input is not a security mechanism by itself.

13. Use Autocomplete Appropriately

The autocomplete attribute can help browsers and password managers identify the expected purpose of fields.

<input
    type="email"
    name="email"
    autocomplete="email">

<input
    type="password"
    name="password"
    autocomplete="current-password">

14. Never Treat Hidden Fields as Secret

A hidden input is not actually hidden from the user. Its value can be inspected or modified in the browser.

<input
    type="hidden"
    name="role"
    value="student">

15. Safe File Upload Forms

File uploads require special security controls.

<form
    action="/upload"
    method="post"
    enctype="multipart/form-data">

    <label for="document">
        Upload Document
    </label>

    <input
        id="document"
        name="document"
        type="file"
        accept=".pdf,.docx"
        required>

    <button type="submit">
        Upload
    </button>

</form>

The accept attribute helps guide the user, but it is not a security boundary.

16. Understand the Limits of the Accept Attribute

<input
    type="file"
    name="photo"
    accept="image/*">

This guides the browser's file-selection interface. It does not prove that an uploaded file is safe or genuinely has the expected content.

17. Be Careful with User-Controlled URLs

Applications that accept URLs from users should validate and safely handle them according to the application's requirements.

<input
    type="url"
    name="website"
    autocomplete="url">

The type="url" attribute provides browser validation and user-interface support, but it does not automatically make the destination trustworthy.

18. External Links and New Tabs

When opening an external destination in a new browsing context, understand the security and privacy implications of the chosen link attributes.

<a
    href="https://example.com"
    target="_blank"
    rel="noopener">

    Visit External Resource

</a>

19. Content Security Policy (CSP)

A Content Security Policy is a browser security mechanism that can restrict where different types of resources may be loaded and can help reduce the impact of certain injection attacks.

CSP is normally configured using HTTP response headers.

Content-Security-Policy:
    default-src 'self';

20. HTML vs HTTP Security

Some important security controls are not HTML elements at all. They are normally configured by the web server or application platform.

21. Safe HTML Output

When displaying user-generated content, the application must distinguish between text and HTML markup.

Example Input

<script>alert("Unexpected code")</script>

If this is intended to be displayed as ordinary text, it must not be interpreted as executable HTML/JavaScript.

22. Prefer Safe Text Insertion

When using JavaScript to insert ordinary user-provided text, APIs intended for text content are generally safer than interpreting the value as HTML.

element.textContent = userInput;

Be cautious with APIs that interpret strings as HTML when the source data is untrusted.

23. Verify Form Destinations

The action attribute determines where form data is submitted.

<form
    action="/account/update"
    method="post">

    ...

</form>

Developers should ensure that form destinations are intentional and that sensitive data is not accidentally sent to an untrusted third-party destination.

24. Do Not Put Sensitive Information in URLs

URLs may be recorded in browser history, logs, analytics systems, referrer information and other infrastructure.

/reset?password=MySecretPassword

25. Safe Password Reset Forms

Password reset systems require server-side security controls. The HTML form itself is only the user interface.

<form
    action="/account/reset-password"
    method="post">

    <label for="new-password">
        New Password
    </label>

    <input
        id="new-password"
        name="new_password"
        type="password"
        autocomplete="new-password"
        required>

    <button type="submit">
        Reset Password
    </button>

</form>

The server must independently verify the reset authorization, enforce password policy and securely store passwords.

26. Never Trust Client-Side Authorization

Hiding a button does not prevent a user from calling the underlying server endpoint.

<button
    hidden>

    Delete Account

</button>

A user could still attempt to send a request directly.

27. Security by Design

Security should be considered from the beginning of the development lifecycle.

1. Identify sensitive data.
2. Identify possible attack surfaces.
3. Validate untrusted input.
4. Encode output appropriately.
5. Enforce authentication and authorization server-side.
6. Use secure transport.
7. Protect sessions and cookies.
8. Test security controls.
9. Keep dependencies and infrastructure updated.

28. Privacy-Friendly Forms

Collect only information that is necessary for the stated purpose of the application.

Example

If an online course registration requires an email address, avoid unnecessarily collecting unrelated personal information.

29. Complete Safe HTML Form Example

<form
    action="/contact"
    method="post"
    autocomplete="on">

    <div>

        <label for="full-name">
            Full Name
        </label>

        <input
            id="full-name"
            name="full_name"
            type="text"
            autocomplete="name"
            minlength="2"
            maxlength="100"
            required>

    </div>


    <div>

        <label for="email">
            Email Address
        </label>

        <input
            id="email"
            name="email"
            type="email"
            autocomplete="email"
            required>

    </div>


    <div>

        <label for="message">
            Message
        </label>

        <textarea
            id="message"
            name="message"
            minlength="10"
            maxlength="2000"
            required></textarea>

    </div>


    <button type="submit">
        Send Message
    </button>

</form>

30. Common Security Mistakes

31. Interview Questions

32. Exam Questions

33. Practical Task — Secure Registration Form

Create a registration form containing:

1. Full name
2. Email address
3. Password
4. Confirm password
5. Date of birth
6. Country
7. Terms and conditions checkbox
8. Submit button

HTML Requirements

• Use semantic HTML.
• Use labels correctly.
• Use meaningful IDs and names.
• Use suitable input types.
• Use appropriate autocomplete values.
• Use HTML validation attributes.
• Do not place passwords in URLs.
• Do not use hidden fields for authorization.

Advanced Security Requirements

• Use HTTPS.
• Perform server-side validation.
• Hash passwords securely on the server.
• Use parameterized database queries.
• Protect state-changing requests appropriately.
• Safely encode user-generated output.

34. HTML Security Audit Checklist