Secure Code in Java and Spring Boot: Build Resilient Apps

• What is OWASP

• What is OWASP Top 10

• Why OWASP Top 10 is important

• OWASP Top 10 2021

• What is Common Weakness Enumeration (CWE)

• What are Common Vulnerabilities and Exposures (CVE)

• What is the Common Vulnerability Scoring System (CVSS)

• OWASP Top 10 2017 VS OWASP 2021

• What is Access Control

• Authorization VS Authentication

• Types of Access Control

• OAuth (Overview)

• JWT (Overview)

• What is Broken Access Control

• Impact

• Insecure ID Vulnerability

• Path Traversal Vulnerability

• Poison Null Bytes Attack

• Safelisting

• Client Caching Vulnerability

• Violation of the principle of least privilege

• Elevation of privilege

• Review Roles Management Approach

• How to prevent (including design solutions)

• Example of Attack Scenarios

• Cryptographic Failures: Overview

• The most common root causes

• Comparative analysis between OWASP Top 10 2017 & 2021

• Notable Common Weakness Enumerations

• Types of cryptographic failures

• Personal data VS Sensitive data

• Types of sensitive data

• Cryptographic Failure vs. Data Breach

• What leads to cryptographic failures

• Example of attack scenraios

• SQL Injections

• TLS & SSL

• HTTPS VS HTTP

• Enabling HTTPS on Tomcat web server

• Example of attack scenraios

• Password encryption practical exercise

• Passwords hashing

• Salted passwords

• Hashing algorithms (MD5, SHA, PBKDF2, BCrypt, and SCrypt)

• How to prevent cryptographic failures

• Injection Risk Category: Overview

• Fuzzing

• Notable Common Weakness Enumerations (CWEs)

• Impact

• Comparison of Injection in OWASP Top 10 2021 and 2017

• Injection Types

• Command Injection

• Cross Site Scripting

• Types of Cross Site Scripting

• SQL Injection

• JPA Injection

• NoSQL Injection

• XML: XPath Injection

• Log Injection

• How to prevent injection vulnerabilities

• Input Validation: Goals

• Input Validation: Strategies

• Input Validation: Techniques

• Insecure Design Overview

• Insecure Design VS Insecure Implementation

• Shift left security approach

• Notable CWEs

• What is secure design

• Threat Modeling

• Goal of threat modeling

• Threat Modeling Manifesto: Overview

• Threat Modeling Manifesto: Values

• Threat Modeling Manifesto: Principles

• Build a secure design process

• Business impact analysis

• Working with threat register

• Security controls

• Security design document

• Secure Design Process Metrics

• Example of Attacks

• How to prevent

• Overview

• Potential Impact

• Notable CWEs

• Security Misconfiguration in OWASP Top 10 2021 VS 2017

• Types of security misconfiguration

• Examples of real-life attacks

• Federated Architecture

• Security Hardening

• Zero Trust Security Model

• NIST 800-207

• Defense in Depth

• NIST 800-123

• Best Practices for System Hardening

• Example of Attacks - Demo

• How to prevent

• Overview

• Risk Factors

• Why it is hard to update outdated components

• Notable CWEs

• How attackers use vulnerable components

• Real-life example

• OWASP Top 10 2021 VS 2017

• Demo of dependency check plugin

• Vulnerability scanners

• How to prevent

• Overview

• Potential Impact

• Notable CWEs

• OWASP Top 10 2017 VS 2021

• How attackers exploit authentication failures

• Session fixation

• Cross-Site Request Forgery (CSRF)

• Execution After Redirect (EAR)

• Risk factors

• Multi-factor authentication (MFA)

• Review of different factors

• Session ID Entropy

• Examples of Attacks

• Credential stuffing

• Brute force access

• Session hijacking

• How to prevent

• Overview

• Potential impact review

• Common Weakness Enumerations

• OWASP Top 10 2017 VS 2021

• Examples of Attacks

• How to prevent

• What is logging and logs

• Overview of Security Logging and Monitoring Failures Category

• Potential Impact

• Risk Factors

• Challenges

• Log Management Tools

• Libraries for Logging in Java

• Notable Common Weakness Enumerations

• OWASP Top 10 2017 VS 2021

• Attack Examples

• How to Prevent

• Overview

• Trust relationships

• Risk factors

• Potential impact

• Types of SSRF

• OWASP Top 10 2017 VS 2021

• Capital One Incident: Overview

• SSRF Java Example

• Examples of Attacks

• How to prevent

• Definition of Object-Level Authorization and Its Importance

• Explanation of BOLA Vulnerabilities and Their Prevalence in APIs

• Connection to OWASP Top 10: Broken Access Control

• Real-world examples of data breaches due to BOLA

• Consequences for organizations and users of not adhering to BOLA best practices

• Insecure Coding Practices Leading to BOLA

Code examples demo: Problem & Solution - Online Shop Example

• Enforcing robust authorization mechanisms

• Continuous testing and validation of authorization logic

• Using Random Universally Unique Identifiers (UUIDs)

• Implementation considerations when integrating UUIDs into API ecosystems

• Securing the Business Logic Layer

• Implementing Zero-Trust Security Model

• How zero-trust principles mitigate BOLA vulnerabilities.

• Understanding Broken Authentication - Definition

• Common Misconceptions about API Authentication

• Authentication Mechanisms and Their Vulnerabilities

• Ease of detecting authentication issues with current methodologies.

• Connection with OWASP Top 10 Broken Access Control

• Distinguishing Between Authentication and Access Control

• How Broken Authentication Can Lead to Broken Access Control

• Examples of Interconnected Vulnerabilities and Exploits

• Causes of Broken Authentication

• Types of Attacks

• Technical Factors Contributing to Vulnerabilities

• Automated Attacks

• Poor Standards and Practices

• Lack of Protection Mechanisms

• Misimplementation of Authentication Mechanisms

• Case Studies

• Lessons Learned from Case Studies

• Impact and Consequences of Broken Authentication Vulnerabilities

• Best Practices for Mitigating Broken Authentication

• OAuth VS Open ID

• Real Life Code Example - Demo of Problem and Solution

• Timing Attacks and How to Avoid Them

• Definition of Broken Object Property Level Authorization

• Importance in API security

• Threat Agents and Attack Vectors

• Security weaknesses and their impacts

• Real-world consequences of vulnerabilities

• Example Review - Scenario #1: Fitness App Workout Tracking

• Example Review - Scenario #2: Online Learning Platform Quiz Submissions

• Prevention Measures -

  • Implementing access controls

  • Minimizing Data Exposure

  • Using Schema-Based Validation

  • Avoiding Client-Side Filtering Reliance

• Related Concepts:

  • Excessive Data Exposure (OWASP API3:2019)

  • Mass Assignment (OWASP API6:2019)

• Online Shop: Practical Example Source Code Review

• Definition of Unrestricted Resource Consumption

• Threat Agents and Attack Vectors

• Typical design flaws and configuration issues

• Technical Impact Analysis

• Business Impact Analysis

• Real-World Examples of Unrestricted Resource Consumption

• SMS Abuse Leading to Financial Loss (NordVPN)

• Increased Cloud Storage Costs (File Download Service)

• DDoS Attack on Poland’s Tax Portal

• CWE-770: Allocation of Resources Without Limits or Throttling

• CWE-400: Uncontrolled Resource Consumption

• CWE-799: Improper Control of Interaction Frequency

• Detection of Unrestricted Resource Consumption

• Prevention Strategies

• Best Practices

• Practical Example Source Code Review - Problem & Solution

• Definition and explanation of BFLA

• Difference between BFLA and Broken Object Level Authorization

• Root Causes of BFLA

• Attack Scenarios and Examples

• Potential Consequences of BFLA

• How to Detect BFLA

• Prevention Techniques for BFLA

Practical Example Source Code Review - Problem & Solution

• Definition of Unrestricted Access to Sensitive Business Flows

• Importance of understanding this vulnerability

• How UASBF differs from other API vulnerabilities

• How attackers exploit UASBF

• Common Scenarios and Examples

• Examples of Business Logic Abuse

• Challenges in detection and protection

• How to Address These Challenges

• Potential impacts on businesses

• Case Study Analysis

• Real-Life Example: Airline Ticketing Abuse

• Prevention and Mitigation - Business Layer

• Prevention and Mitigation - Engineering Layer

• Testing for UASBF

• Best Practices

• Practical Example Source Code Review - Problem & Solution

• Introduction to SSRF

• Similarities Between API7:2023 and A10:2021

• Differences Between API7:2023 and A10:2021

• Attack Scenarios in API7:2023

• Prevention Strategies

• Summary and Conclusion

• Introduction to Security Misconfiguration

• Similarities Between API8:2023 and A05:2021

• Differences Between API8:2023 and A05:2021

• Attack Scenarios in API8:2023

• Prevention Strategies

• Summary and Conclusion

• Definition and significance of API inventory management

• Common challenges in maintaining API inventories

• The role of proper inventory management in API security

• Discussion of Key Risks:

  • Exploitation of Vulnerabilities

  • Amplification of Risks

  • Cross-Compatibility Issues

• Real-World Examples of Security Breaches Due to Poor Inventory Management

• Legacy APIs and Their Challenges

• The Balance Between Backward Compatibility and Security

• Strategies for Effective API Inventory Management

• Practical Example Source Code Review - Problem & Solution

• Definition and Importance

• Common Misconceptions About API Security

• Why APIs are Vulnerable

• Key Vulnerabilities in Unsafe Consumption of APIs

• Key Risks Associated with Unsafe API Consumption

• Real-World Examples and Case Studies

• How to Spot Unsafe API Consumption Vulnerabilities

• Mitigation Strategies

• Best Practices

• Practical Example Source Code Review - Problem & Solution

• OWASP Top 10: Setting the Stage

• From Web Security to AI and LLMs: A New Threat Landscape

• How the OWASP Top 10 (2025) Was Created

• OWASP Top 10 (2025): An Overview of the Categories

• Why the OWASP Top 10 Matters for Developers and Organizations

• How We Will Work with the OWASP Top 10 (2025) and What You Will Learn

• Introduction to Prompt Injection

• Types of Prompt Injection

• Impact of Prompt Injection Attacks

• Practical Examples & Attack Demonstrations

• Best Practices and Defensive Patterns

• Introduction to Sensitive Information Disclosure

• Common Vulnerabilities and Risks

• Example Attack Scenarios

• Prevention and Mitigation Strategies

• Best Practices and Defensive Patterns

• Introduction to LLM Supply Chain Security

• Common Supply Chain Vulnerabilities

• Practical Examples and Real-World Case Studies

• Prevention and Mitigation Strategies

• Best Practices and Defensive Patterns

• Introduction to Data and Model Poisoning

• Common Vulnerabilities and Risks

• Real-World Attack Scenarios

• Prevention and Mitigation Strategies

• Best Practices and Defensive Patterns

• Introduction to Improper Output Handling

• Common Vulnerabilities

• Real-World Attack Scenarios

• Prevention and Mitigation Strategies

• Best Practices and Defensive Patterns

• Introduction to Excessive Agency

• Common Risks and Root Causes

• Practical Examples of Vulnerabilities

• Real-World Attack Scenarios

• Prevention and Mitigation Strategies

• Best Practices and Defensive Patterns

• Introduction to System Prompt Leakage

• Common Risks and Vulnerabilities

• Practical Examples

• Real-World Attack Scenarios

• Prevention and Mitigation Strategies

• Best Practices and Defensive Patterns

• Introduction to Vector and Embedding Weaknesses

• Common Risks and Vulnerabilities

• Practical Examples of Vulnerabilities

• Real-World Attack Scenarios

• Prevention and Mitigation Strategies

• Best Practices and Defensive Patterns

• Introduction to Misinformation in LLMs

• Common Risks and Real-World Failures

• Practical Examples

• Real-World Attack Scenarios

• Prevention and Mitigation Strategies

• Best Practices and Defensive Patterns

• Introduction to Unbounded Consumption

• Common Vulnerabilities and Risks

• Practical Examples

• Real-World Attack Scenarios

• Prevention and Mitigation Strategies

• Best Practices and Defensive Patterns

• Introduction and overview

• Authentication

• Authorization

• Authentication VS Authorization

• Technologies that support Spring Security Integration

• Advantages

• Spring Security Features

• Spring Security Modules

• High level Spring Security Authentication & Authorization architecture

• First Spring Security Project

• Spring Security Dependencies

• Spring Security Configuration

• InMemoryUserDetailsManager bean

• PasswordEncoder bean

• SecurityFilterChain bean

• CSRF

• anonymous() VS permitAll()

• AuthenticationFailureHandler

• LogoutSuccessHandler

• Login with the custom login form in Spring Security

• Login with the default login form

• First Spring Security Project

• Spring Security Dependencies

• Spring Security Configuration

• InMemoryUserDetailsManager bean

• PasswordEncoder bean

• SecurityFilterChain bean

• CSRF

• anonymous() VS permitAll()

• AuthenticationFailureHandler

• LogoutSuccessHandler

• Login with the custom login form in Spring Security

• Login with the default login form

• Remember Me feature in Spring Security

• RememberMeConfigurer Overview

• Coding exercise with Remember Me

• Security at method level

• Spring Expression Language

• @PreAuthorize

• @PostAuthorize

• @Secured

• @EnableMethodSecurity

• Spring Security Architecture

• Authentication Filter

• Spring Security Context

• Authentication Manager

• Authentication Provider

• User Details Service

• Password Encoder

• Business need in implementing custom Authentication Provider

• Code examples of custom Authentication Provider

In this lesson we are going to review EXAM task about integration of the Spring Security into our Online Shop application.

Also, we are going to review source code of the solution in the video.

• Where start learning

• Spring Framework VS Spring Boot

• What is Spring Boot

• Features of Spring Boot

• Opinionated development approach

• When to use Spring Boot

• When not to use Spring Boot

• Advantages & Disadvantages

• Spring Initializr Web Tool

• Spring Boot project generation

• Spring Tools for Eclipse IDE

• Simple MVC controller in Spring Boot

• Practical exercise

• What are starters

• Why do we need starters

• Advantages of using starters

• List of spring boot starters

• Practical exercises

• How to add spring boot starter

• Web starter

• REST API Development in Spring Boot

• Test starter

• Data JPA Starter

• Configuration of H2 Database in Spring Boot

• Configuration of MySQL Database in Spring Boot

• Security starter

• Application properties: Overview

• Precedence order of properties

• Overriding properties

• Default Spring Boot properties

• List of Spring Boot properties

• Practical examples

• Changing the port number

• SSL/TLS configuration in Spring Boot

• Generation of self-signed certificate for TLS

• Changing of context path of the application

• Configuration of logging level

• @ConfigurationProperties annotation

• What is Spring Boot Actuator

• JMX Beans

• Features and benefits of Spring Boot Actuator

• Predefined endpoints

• Adding dependency for Spring Boot Starter Actuator

• How to expose all available endpoints

• How to exclude specific endpoints

• Change base path

• Fetch application metrics

• Best practices of working with Actuator

• Introduction to OAuth and JWT

• How OAuth and JWT works

• How JWT are signed and verified

• What is an Identity Provider

• OAuth VS OAuth 2.0

• What is an OpenID Connect

• OIDC VS OAuth

• Identity Provider & User Management

• Introduction of Auth0

• Configuration plan overview

• Live demo

  • Create an Auth0 account and tenant

  • Register a new application

  • Configure the application settings

  • Grant Types

  • Open ID Connect settings

  • Configure test users

  • Configure API permissions

• Setting up a Spring Boot project

• Adding OAuth2 dependencies

• Spring Boot Starters

  • spring-boot-starter-oauth2-client

  • spring-boot-starter-oauth2-resource-server

• Demo of OpenID connect client flow

• Logout from the app and identity provider

• Demo of machine to machine flow

• Configuration of the OAuth server

• Spring Boot configurations and properties

• Testing of Spring Boot Endpoints, OAuth/OpenID Connect, and Configuration

• spring-boot-starter-test

• How to test a @Controller

• @SpringBootTest

• @AutoConfigureMockMvc

• MockMvc

• Naming conventions, coding style recommendations

• PropertyOverrideInitializer and ApplicationContextInitializer

• @WebMvcTest

• @MockitoBean

• RestTemplateBuilder

• @LocalServerPort

• SpringBootTest.WebEnvironment.RANDOM_PORT

• TestRestTemplate

• Integration test with Spring Boot

• @DynamicPropertySource

• Understanding Brute-Force Attacks

• What Is a Denial of Service (DoS) Attack

• Why Spring Security Doesn’t Protect Against DoS and Brute-Force by Default

• Understanding Rate Limiting and Its Real-World Applications

• Approaches to Rate Limiting: Strategies and Algorithms

• Overview of Popular Java Libraries for Rate Limiting

• Demo: real-life code examples

• Best Practices for Rate Limiting: Protecting Against DDoS and Brute Force Attacks

• What is Resilience and Why It Matters

• Real-Life Failures & Why Resilience Is Needed

• Introduce Common Resilience Patterns

• Circuit Breaker Pattern Explained

• Introducing Resilience4j: Practical Fault Tolerance for Modern Java

• Practical Demo - Code Examples

• Configure Resilience4j Library in Sprig Boot project

• Circuit Breaker Pattern - Implementation & Demo

• What the Retry pattern is and why it’s important in resilient systems

• Common scenarios where retries are useful, especially in distributed applications

• A clear explanation of the Retry mechanism, using real-life analogies

• Smart Retry Strategies: Backoff, Limits, and Exception Filtering

• Live code walkthrough and demo of the retry pattern in action

• RetryEventListener

• How to use Circuit Breaker together with Retry

• What is the Time Limiter Pattern and Why It Matters

• Real-World Scenarios Where Time Limits Prevent Failures

• Introduction to Resilience4j TimeLimiter Module

• Using CompletableFuture with TimeLimiter

• Live Code Demo and Testing the Time Limiter in Action

• Rate Limiting Recap: Why It Matters and What It Solves

• Why Use Resilience4j for Rate Limiting in Modern Applications

• Differences Between Bucket4j and Resilience4j: When and Why to Use Each

• How Token-Based Limiting Works in Resilience4j

• Live Demo: Rate Limiting in Action with Real API Endpoints

• Introduction to the Bulkhead Pattern: What It Is and Why It Matters

• Real-World Scenarios Where Bulkheads Prevent Cascading Failures

• Types of Bulkheads: Thread Pool vs. Semaphore Isolation

• How Resilience4j Implements Bulkhead Control

• Live Code Walkthrough and Demo

• Best Practices for Applying Bulkheads in Microservices

• Introduction to Microservice Architectural Patterns

• Overview of the following patterns: API Gateway, Service Discovery, Strangler Fig, Sidecar, Saga, CQRS, Event Sourcing, Backend for Frontend

• Overview of API Gateway Pattern: What, Why, and When to Use

• API Gateway: Key Advantages

• API Gateway: Common Limitations

• Typical Use Cases and Scenarios for API Gateway

• How API Gateway Enhances Security

• How API Gateway Enhances System Resilience

• Creating a Project with Spring Cloud Gateway

• Configuring Routing and Request Forwarding

• Code Examples: Live Demonstration

• What is Load Balancing: Definition and Purpose

• Why Load Balancers Matter in Distributed Systems

• When to Use a Load Balancer and Typical Scenarios

• Relationship Between Load Balancer and API Gateway

• Core Load Balancing Strategies Explained (Round Robin, Random, Least Connections, Weighted, Sticky Sessions, etc.)

• Pros and Cons of Each Strategy

• Overview of Spring Cloud LoadBalancer

• Health Checks and Resilience: Avoiding faulty instances, retries, circuit breakers

• Common Pitfalls and Anti-patterns: What to avoid when implementing load balancing

• Adding Spring Cloud LoadBalancer dependency in pom.xml

• Configuring LoadBalancer via application.properties

• Implementing different load balancing strategies

• Random load balancing strategy in action

• Creating and applying a custom load balancing strategy

• Enabling and demonstrating load balancing with health checks

• Definition and importance of Cybersecurity

• Overview of current cyber threat landscape - Types of Threats

• Malware, phishing attacks, Denial of Service (DoS) attacks, insider threats, social engineering, advanced persistent threats (APTs)

• Case studies of real-world cyber attacks

• Introduction to Threat Analysis Models

  • STRIDE

  • DREAD

  • Parkerian Hexad

  • Attack Trees

• Overview of OWASP and its role in Cybersecurity

• OWASP Application Security Verification Standard (ASVS)

• Security testing tools

• Security architecture design and best practices

• Secure by design principles and their importance

• Types of security controls (preventive, detective, corrective)

• Writing and maintaining a security design document (SDD)

• Importance of documenting security requirements and controls

• Overview of Security Operations Center (SOC)

• Incident Management and Its role in Cybersecurity

List 1: Best Practices for Code Security - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Implementation of checksums or hashes for verifying the integrity of interpreted code, libraries, executables, and configuration files.

• Avoidance of passing user-supplied data to any dynamic execution function.

• Use of tested and approved managed code instead of creating new unmanaged code for common tasks.

Moderate Relevance (Common Security Concerns):

• Protection of shared variables and resources from inappropriate concurrent access.

• Review of all secondary applications, third-party code, and libraries to determine business necessity and validate safe functionality.

• Delay in raising elevated privileges until necessary, with prompt dropping of those privileges as soon as possible.

Low Relevance (Edge Cases and Lesser-known Threats):

• Utilization of task-specific built-in APIs for conducting operating system tasks, avoiding direct commands to the Operating System through application-initiated command shells.

• Implementation of safe updating practices, including the use of cryptographic signatures for code.

• Explicit initialization of all variables and data stores, either during declaration or prior to first usage.

• Restriction of user capabilities to generate new code or alter existing code.

• Use of locking mechanisms to prevent multiple simultaneous requests or synchronization mechanisms to avoid race conditions.

• Awareness of calculation errors through understanding the programming language's underlying representation.

List 2: Best Practices for Code Security - Ordered by Complexity

Basic (Beginner):

• Explicit initialization of all variables and data stores, either during declaration or prior to first usage.

• Restriction of user capabilities to generate new code or alter existing code.

• Protection of shared variables and resources from inappropriate concurrent access.

Intermediate:

• Use of locking mechanisms to prevent multiple simultaneous requests or synchronization mechanisms to avoid race conditions.

• Delay in raising elevated privileges until necessary, with prompt dropping of those privileges as soon as possible.

• Utilization of task-specific built-in APIs for conducting operating system tasks, avoiding direct commands to the Operating System through application-initiated command shells.

Advanced:

• Implementation of checksums or hashes for verifying the integrity of interpreted code, libraries, executables, and configuration files.

• Review of all secondary applications, third-party code, and libraries to determine business necessity and validate safe functionality.

• Avoidance of passing user-supplied data to any dynamic execution function.

• Implementation of safe updating practices, including the use of cryptographic signatures for code.

• Use of tested and approved managed code instead of creating new unmanaged code for common tasks.

• Awareness of calculation errors through understanding the programming language's underlying representation.

List 1: Data Validation Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

1. Client Data Validation before processing, including parameters, URLs, HTTP headers, and automated postbacks (e.g., JavaScript, Flash, etc.)

2. Data Validation on Trusted Systems (e.g., The server)

3. Classification of Data Sources into trusted and untrusted. Validation required for all data from untrusted sources.

4. Whitelist-Based Input Validation for allowed characters; implement additional controls for hazardous characters such as < > " ' % ( ) & + \ \' \".

5. Centralized Input Validation Routine for the application

Moderate Relevance (Common Security Concerns):

1. Redirect Data Validation (to avoid bypassing application logic and validation before redirect)

2. Canonicalization Process (Encoding data to a common character set before validation)

3. UTF-8 Character Set Support Validation post-decoding

4. Character Set Specification such as UTF-8 for all input sources

5. Data Length Validation

6. Data Type Validation

7. Data Range Validation

Low Relevance (Edge Cases and Lesser-known Threats):

1. ASCII Header Value Verification

2. Input Rejection on Validation Failure

3. Discrete Validation Checks for inputs not covered by standard routines:

   • Null Byte Validation (%00)

   • New Line Character Validation (%0d, %0a, \r, \n)

   • Path Traversal Validation (../ or ..)

List 2: Data Validation Best Practices - Ordered by Complexity

Basic (Beginner):

1. Data Type Validation

2. Data Range Validation

3. Data Length Validation

4. Input Rejection on Validation Failure

5. ASCII Header Value Verification

Intermediate:

1. Classification of Data Sources into trusted and untrusted. Validation required for all data from untrusted sources.

2. Client Data Validation before processing, including parameters, URLs, HTTP headers, and automated postbacks (e.g., JavaScript, Flash, etc.)

3. Character Set Specification such as UTF-8 for all input sources

4. Redirect Data Validation (to avoid bypassing application logic and validation before redirect)

5. UTF-8 Character Set Support Validation post-decoding

Advanced:

1. Data Validation on Trusted Systems (e.g., The server)

2. Canonicalization Process (Encoding data to a common character set before validation)

3. Centralized Input Validation Routine for the application

4. Whitelist-Based Input Validation for allowed characters; implement additional controls for hazardous characters such as < > " ' % ( ) & + \ \' \".

5. Discrete Validation Checks for inputs not covered by standard routines:

   • Null Byte Validation (%00)

   • New Line Character Validation (%0d, %0a, \r, \n)

Path Traversal Validation (../ or ..) with UTF-8 extended character set handling

List 1: Best Practices for Data Encoding and Sanitization - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Contextual sanitization of all output containing untrusted data for SQL, XML, and LDAP queries.

• Sanitization of all output with untrusted data for operating system commands.

• Contextual output encoding of all data returned to the client that originated outside the application's trust boundary; HTML entity encoding is one example, though not universally applicable.

Moderate Relevance (Common Security Concerns):

• Encoding of all characters unless they are confirmed safe for the intended interpreter.

• Utilization of a standard, tested routine for each type of outbound encoding.

Low Relevance (Edge Cases and Lesser-known Threats):

• Conducting all encoding on a trusted system (e.g., the server).

List 2: Best Practices for Data Encoding and Sanitization - Ordered by Complexity

Basic (Beginner):

• Encoding of all characters unless they are confirmed safe for the intended interpreter.

• Conducting all encoding on a trusted system (e.g., the server).

Intermediate:

• Utilization of a standard, tested routine for each type of outbound encoding.

• Contextual output encoding of all data returned to the client that originated outside the application's trust boundary; HTML entity encoding is one example, though not universally applicable.

Advanced:

• Contextual sanitization of all output containing untrusted data for SQL, XML, and LDAP queries.

• Sanitization of all output with untrusted data for operating system commands.

List 1: Authentication Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Requirement of authentication for all pages and resources, except those specifically intended to be public.

• Enforcement of all authentication controls on a trusted system (e.g., the server).

• Secure failure of all authentication controls.

• Encryption and protected storage of authentication credentials for accessing services external to the application on a trusted system (e.g., the server), avoiding source code as a secure location.

• Indistinct authentication failure responses that do not specify which part of the authentication data was incorrect (e.g., "Invalid username and/or password").

• Prevention of password re-use.

• Requirement for password reset and changing operations to have the same level of controls as account creation and authentication.

Moderate Relevance (Common Security Concerns):

• Establishment and utilization of standard, tested authentication services whenever possible.

• Centralized implementation for all authentication controls, including libraries that call external authentication services.

• Enforcement of password complexity and length requirements established by policy or regulation.

• Obscuring of password entry on the user's screen (e.g., "password" input type on web forms).

• Enforcement of account disabling after an established number of invalid login attempts (e.g., five attempts).

• Notification of users upon occurrence of a password reset.

• Re-authentication of users prior to performing critical operations.

• Use of Multi-Factor Authentication for highly sensitive or high-value transactional accounts.

Low Relevance (Edge Cases and Lesser-known Threats):

• Segregation of authentication logic from the requested resource, with redirection to and from the centralized authentication control.

• Management of a credential store ensuring storage of cryptographically strong one-way salted hashes of passwords, avoiding the MD5 algorithm if possible.

• Validation of authentication data only upon completion of all data input, particularly for sequential authentication implementations.

• Use of only HTTP POST requests to transmit authentication credentials.

• Short expiration time for temporary passwords and links, along with enforced changes upon next use.

• Disabling of "remember me" functionality for password fields.

• Reporting of the last use (successful or unsuccessful) of a user account to the user at the next successful login.

• Monitoring of attacks against multiple user accounts using the same password.

• Change or disabling of all vendor-supplied default passwords and user IDs.

• Enforcement of password changes based on requirements established in policy or regulation.

List 2: Authentication Best Practices - Ordered by Complexity

Basic (Beginner):

• Requirement of authentication for all pages and resources, except those specifically intended to be public.

• Indistinct authentication failure responses that do not specify which part of the authentication data was incorrect (e.g., "Invalid username and/or password").

• Prevention of password re-use.

• Obscuring of password entry on the user's screen (e.g., "password" input type on web forms).

• Short expiration time for temporary passwords and links, along with enforced changes upon next use.

• Disabling of "remember me" functionality for password fields.

Intermediate:

• Enforcement of all authentication controls on a trusted system (e.g., the server).

• Establishment and utilization of standard, tested authentication services whenever possible.

• Centralized implementation for all authentication controls, including libraries that call external authentication services.

• Encryption and protected storage of authentication credentials for accessing services external to the application on a trusted system (e.g., the server).

• Enforcement of password complexity and length requirements established by policy or regulation.

• Enforcement of account disabling after an established number of invalid login attempts (e.g., five attempts).

• Notification of users upon occurrence of a password reset.

• Validation of authentication data only upon completion of all data input, particularly for sequential authentication implementations.

• Re-authentication of users prior to performing critical operations.

• Use of only HTTP POST requests to transmit authentication credentials.

Advanced:

• Secure failure of all authentication controls.

• Segregation of authentication logic from the requested resource, with redirection to and from the centralized authentication control.

• Management of a credential store ensuring storage of cryptographically strong one-way salted hashes of passwords, avoiding the MD5 algorithm if possible.

• Use of Multi-Factor Authentication for highly sensitive or high-value transactional accounts.

• Monitoring of attacks against multiple user accounts using the same password.

• Reporting of the last use (successful or unsuccessful) of a user account to the user at the next successful login.

• Change or disabling of all vendor-supplied default passwords and user IDs.

• Enforcement of password changes based on requirements established in policy or regulation.

List 1: Session Management Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Full termination of the associated session or connection through logout functionality.

• Creation of session identifiers on a trusted system (e.g., the server).

• Use of well-vetted algorithms for session management controls to ensure sufficiently random session identifiers.

• Prevention of session identifier exposure in URLs, error messages, or logs. Session identifiers should only be located in the HTTP cookie header, not passed as GET parameters.

• Protection of server-side session data from unauthorized access through appropriate access controls on the server.

• Generation of a new session identifier when the connection security changes from HTTP to HTTPS, with consistent use of HTTPS recommended throughout the application.

• Disallowance of persistent logins and enforcement of periodic session terminations, even when sessions are active.

Moderate Relevance (Common Security Concerns):

• Periodic generation of a new session identifier and deactivation of the old one to mitigate session hijacking risks.

• Generation of a new session identifier upon re-authentication.

• Establishment of a session inactivity timeout that balances risk and business requirements, typically no longer than several hours.

• Prohibition of concurrent logins with the same user ID.

• Setting of the domain and path for cookies containing authenticated session identifiers to a restricted value for the site.

• Closure of any pre-login session and establishment of a new session after a successful login.

Low Relevance (Edge Cases and Lesser-known Threats):

• Setting of the "secure" attribute for cookies transmitted over a TLS connection.

• Setting of cookies with the HttpOnly attribute, unless client-side scripts specifically require access to read or set a cookie's value.

• Supplementation of standard session management for sensitive server-side operations (e.g., account management) by utilizing per-session strong random tokens or parameters to prevent CSRF attacks.

• Supplementation of standard session management for highly sensitive or critical operations by using per-request strong random tokens or parameters.

• Availability of logout functionality on all pages protected by authorization.

List 2: Session Management Best Practices - Ordered by Complexity

Basic (Beginner):

• Use of server or framework-based session management controls, with the application recognizing only these session identifiers as valid.

• Availability of logout functionality on all pages protected by authorization.

• Setting of the domain and path for cookies containing authenticated session identifiers to a restricted value for the site.

• Setting of the "secure" attribute for cookies transmitted over a TLS connection.

• Setting of cookies with the HttpOnly attribute, unless client-side scripts specifically require access to read or set a cookie's value.

Intermediate:

• Creation of session identifiers on a trusted system (e.g., the server).

• Use of well-vetted algorithms for session management controls to ensure sufficiently random session identifiers.

• Generation of a new session identifier upon re-authentication.

• Generation of a new session identifier when the connection security changes from HTTP to HTTPS, with consistent use of HTTPS recommended throughout the application.

• Prohibition of concurrent logins with the same user ID.

• Closure of any pre-login session and establishment of a new session after a successful login.

Advanced:

• Full termination of the associated session or connection through logout functionality.

• Prevention of session identifier exposure in URLs, error messages, or logs. Session identifiers should only be located in the HTTP cookie header, not passed as GET parameters.

• Protection of server-side session data from unauthorized access through appropriate access controls on the server.

• Periodic generation of a new session identifier and deactivation of the old one to mitigate session hijacking risks.

• Establishment of a session inactivity timeout that balances risk and business requirements, typically no longer than several hours.

• Disallowance of persistent logins and enforcement of periodic session terminations, even when sessions are active.

• Supplementation of standard session management for sensitive server-side operations (e.g., account management) by utilizing per-session strong random tokens or parameters to prevent CSRF attacks.

• Supplementation of standard session management for highly sensitive or critical operations by using per-request strong random tokens or parameters.

List 1: Best Practices for Access Control - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Restriction of access to protected URLs to only authorized users.

• Restriction of access to protected functions to only authorized users.

• Restriction of access to application data to only authorized users.

• Secure failure of access controls.

• Denial of all access if the application cannot retrieve its security configuration information.

• Restriction of direct object references to only authorized users.

• Restriction of access to files or resources, including those outside the application's direct control, to only authorized users.

Moderate Relevance (Common Security Concerns):

• Enforcement of authorization controls on every request, including those made by server-side scripts, "includes," and requests from rich client-side technologies like AJAX and Flash.

• Periodic re-validation of a user’s authorization if long authenticated sessions are allowed, with logout and re-authentication if privileges have changed.

• Matching of server-side implementation and presentation layer representations of access control rules.

• Limitation of the number of transactions a single user or device can perform in a given period, set above actual business requirements but low enough to deter automated attacks.

• Segregation of privileged logic from other application code.

• Restriction of access to user and data attributes and policy information used by access controls.

Low Relevance (Edge Cases and Lesser-known Threats):

• Use of encryption and integrity checking on the server side to catch state tampering if state data must be stored on the client.

• Use of the "referer" header as a supplemental check only, never as the sole authorization check, due to its susceptibility to spoofing.

• Implementation of account auditing and enforcement of disabling unused accounts (e.g., after no more than 30 days from the expiration of an account’s password).

• Support for disabling accounts and terminating sessions when authorization ceases (e.g., changes to role, employment status, or business process).

• Application of the least privilege principle to service accounts or accounts supporting connections to or from external systems.

• Creation of an Access Control Policy to document an application's business rules, data types, and access authorization criteria and processes for proper provisioning and control of access.

List 2: Best Practices for Access Control - Ordered by Complexity

Basic (Beginner):

• Restriction of access to protected URLs to only authorized users.

• Restriction of access to protected functions to only authorized users.

• Restriction of access to application data to only authorized users.

• Secure failure of access controls.

• Denial of all access if the application cannot retrieve its security configuration information.

Intermediate:

• Enforcement of authorization controls on every request, including those made by server-side scripts, "includes," and requests from rich client-side technologies like AJAX and Flash.

• Segregation of privileged logic from other application code.

• Periodic re-validation of a user’s authorization if long authenticated sessions are allowed, with logout and re-authentication if privileges have changed.

• Matching of server-side implementation and presentation layer representations of access control rules.

• Restriction of direct object references to only authorized users.

• Limitation of the number of transactions a single user or device can perform in a given period, set above actual business requirements but low enough to deter automated attacks.

Advanced:

• Use of encryption and integrity checking on the server side to catch state tampering if state data must be stored on the client.

• Restriction of access to files or resources, including those outside the application's direct control, to only authorized users.

• Restriction of access to user and data attributes and policy information used by access controls.

• Use of the "referer" header as a supplemental check only, never as the sole authorization check, due to its susceptibility to spoofing.

• Implementation of account auditing and enforcement of disabling unused accounts (e.g., after no more than 30 days from the expiration of an account’s password).

• Support for disabling accounts and terminating sessions when authorization ceases (e.g., changes to role, employment status, or business process).

• Application of the least privilege principle to service accounts or accounts supporting connections to or from external systems.

• Creation of an Access Control Policy to document an application's business rules, data types, and access authorization criteria and processes for proper provisioning and control of access.

List 1: Zero Trust Architecture and Modern Authentication Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Adoption of the Zero Trust principle, where no user or device is trusted by default, even inside the network perimeter.

• Implementation of multi-factor authentication (MFA) across all systems to ensure stronger identity verification.

• Use of biometric verification methods (e.g., fingerprint scanning, facial recognition) for secure user authentication and to prevent credential-based attacks.

• Continuous monitoring and behavioral analytics to detect anomalies in user behavior and identify potential security threats.

• Enforcement of least privilege access based on real-time user behavior, identity, and context, ensuring that users only have the minimum necessary access to resources.

Moderate Relevance (Common Security Concerns):

• Integration of strong identity and access management (IAM) systems to ensure that all users and devices are authenticated and authorized before accessing any resource.

• Segmentation of the network using micro-segmentation to isolate sensitive resources and limit lateral movement in case of a breach.

• Implementation of device trust policies to ensure that only secure, compliant devices are allowed access to critical systems.

• Use of context-aware access controls that take into account the user’s device, location, and time of access to assess the risk before granting access.

• Adoption of zero trust for cloud environments, enforcing identity verification and least privilege for users accessing cloud-based resources.

Low Relevance (Edge Cases and Lesser-known Threats):

• Use of behavioral biometrics (e.g., typing patterns, mouse movements) as an additional authentication layer to enhance security.

• Continuous session validation to ensure that authenticated sessions remain secure over time, with periodic re-authentication when necessary.

• Logging and auditing of all access attempts and activities to ensure full visibility into user and device behavior for detecting and responding to potential threats.

• Implementation of adaptive access policies that can dynamically adjust access privileges based on the risk level of user behavior and context.

• Elimination of VPN reliance, replacing traditional network security approaches with zero trust controls that authenticate and authorize users regardless of network location.

List 2: Zero Trust Architecture and Modern Authentication Best Practices - Ordered by Complexity

Basic (Beginner):

• Adoption of the Zero Trust principle, where no user or device is trusted by default, even inside the network perimeter.

• Enforcement of least privilege access based on real-time user behavior, identity, and context, ensuring that users only have the minimum necessary access to resources.

• Use of multi-factor authentication (MFA) across all systems to ensure stronger identity verification.

• Integration of strong identity and access management (IAM) systems to ensure that all users and devices are authenticated and authorized before accessing any resource.

• Continuous session validation to ensure that authenticated sessions remain secure over time, with periodic re-authentication when necessary.

Intermediate:

• Use of biometric verification methods (e.g., fingerprint scanning, facial recognition) for secure user authentication and to prevent credential-based attacks.

• Continuous monitoring and behavioral analytics to detect anomalies in user behavior and identify potential security threats.

• Implementation of device trust policies to ensure that only secure, compliant devices are allowed access to critical systems.

• Segmentation of the network using micro-segmentation to isolate sensitive resources and limit lateral movement in case of a breach.

• Adoption of zero trust for cloud environments, enforcing identity verification and least privilege for users accessing cloud-based resources.

Advanced:

• Use of context-aware access controls that take into account the user’s device, location, and time of access to assess the risk before granting access.

• Use of behavioral biometrics (e.g., typing patterns, mouse movements) as an additional authentication layer to enhance security.

• Logging and auditing of all access attempts and activities to ensure full visibility into user and device behavior for detecting and responding to potential threats.

• Implementation of adaptive access policies that can dynamically adjust access privileges based on the risk level of user behavior and context.

• Elimination of VPN reliance, replacing traditional network security approaches with zero trust controls that authenticate and authorize users regardless of network location.

List 1: Cryptographic and Logging Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Protection of master secrets from unauthorized access.

• Implementation of all cryptographic functions used to protect secrets on a trusted system (e.g., the server).

• Secure failure of cryptographic modules.

• Generation of random numbers, file names, GUIDs, and strings using an approved cryptographic module's random number generator for un-guessable values.

• Logging of all authentication attempts, with emphasis on failed attempts.

• Logging of all access control failures.

• Logging of all apparent tampering events, including unexpected state data changes.

Moderate Relevance (Common Security Concerns):

• Compliance of cryptographic modules with FIPS 140-2 or an equivalent standard.

• Logging of all input validation failures.

• Logging of all system exceptions.

• Avoidance of sensitive information disclosure in error responses, including system details, session identifiers, or account information.

• Use of cryptographic hash functions to validate log entry integrity.

• Logging of all backend TLS connection failures.

• Logging of cryptographic module failures.

Low Relevance (Edge Cases and Lesser-known Threats):

• Establishment and utilization of a policy and process for cryptographic key management.

• Use of error handlers that do not expose debugging or stack trace details.

• Implementation of generic error messages and custom error pages.

• Handling of application errors directly within the application, not relying solely on server configuration.

• Proper memory deallocation when error conditions occur.

• Denial of access by default in error handling logic associated with security controls.

• Implementation of logging controls on a trusted system (e.g., the server).

• Ensuring logs contain important log event data.

• Prevention of untrusted data in log entries from executing as code in log viewing interfaces or software.

• Restriction of log access to authorized individuals only.

• Utilization of a centralized routine for all logging operations.

• Avoidance of storing sensitive information in logs, such as system details, session identifiers, or passwords.

• Ensuring a mechanism exists for log analysis.

• Logging of attempts to connect using invalid or expired session tokens.

• Logging of all administrative functions, particularly changes to security configuration settings.

List 2: Cryptographic and Logging Best Practices - Ordered by Complexity

Basic (Beginner):

• Avoidance of sensitive information disclosure in error responses, including system details, session identifiers, or account information.

• Use of error handlers that do not expose debugging or stack trace details.

• Implementation of generic error messages and custom error pages.

• Proper memory deallocation when error conditions occur.

• Logging of all authentication attempts, with emphasis on failed attempts.

• Logging of all access control failures.

• Logging of all input validation failures.

• Logging of all system exceptions.

Intermediate:

• Implementation of all cryptographic functions used to protect secrets on a trusted system (e.g., the server).

• Logging of all backend TLS connection failures.

• Logging of cryptographic module failures.

• Logging of all apparent tampering events, including unexpected state data changes.

• Use of cryptographic hash functions to validate log entry integrity.

• Prevention of untrusted data in log entries from executing as code in log viewing interfaces or software.

• Restriction of log access to authorized individuals only.

• Utilization of a centralized routine for all logging operations.

• Ensuring a mechanism exists for log analysis.

Advanced:

• Protection of master secrets from unauthorized access.

• Secure failure of cryptographic modules.

• Generation of random numbers, file names, GUIDs, and strings using an approved cryptographic module's random number generator for un-guessable values.

• Compliance of cryptographic modules with FIPS 140-2 or an equivalent standard.

• Establishment and utilization of a policy and process for cryptographic key management.

• Denial of access by default in error handling logic associated with security controls.

• Implementation of logging controls on a trusted system (e.g., the server).

• Ensuring logs contain important log event data.

• Logging of attempts to connect using invalid or expired session tokens.

• Logging of all administrative functions, particularly changes to security configuration settings.

List 1: Cryptographic and Logging Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Protection of master secrets from unauthorized access.

• Implementation of all cryptographic functions used to protect secrets on a trusted system (e.g., the server).

• Secure failure of cryptographic modules.

• Generation of random numbers, file names, GUIDs, and strings using an approved cryptographic module's random number generator for un-guessable values.

• Logging of all authentication attempts, with emphasis on failed attempts.

• Logging of all access control failures.

• Logging of all apparent tampering events, including unexpected state data changes.

Moderate Relevance (Common Security Concerns):

• Compliance of cryptographic modules with FIPS 140-2 or an equivalent standard.

• Logging of all input validation failures.

• Logging of all system exceptions.

• Avoidance of sensitive information disclosure in error responses, including system details, session identifiers, or account information.

• Use of cryptographic hash functions to validate log entry integrity.

• Logging of all backend TLS connection failures.

• Logging of cryptographic module failures.

Low Relevance (Edge Cases and Lesser-known Threats):

• Establishment and utilization of a policy and process for cryptographic key management.

• Use of error handlers that do not expose debugging or stack trace details.

• Implementation of generic error messages and custom error pages.

• Handling of application errors directly within the application, not relying solely on server configuration.

• Proper memory deallocation when error conditions occur.

• Denial of access by default in error handling logic associated with security controls.

• Implementation of logging controls on a trusted system (e.g., the server).

• Ensuring logs contain important log event data.

• Prevention of untrusted data in log entries from executing as code in log viewing interfaces or software.

• Restriction of log access to authorized individuals only.

• Utilization of a centralized routine for all logging operations.

• Avoidance of storing sensitive information in logs, such as system details, session identifiers, or passwords.

• Ensuring a mechanism exists for log analysis.

• Logging of attempts to connect using invalid or expired session tokens.

• Logging of all administrative functions, particularly changes to security configuration settings.

List 2: Cryptographic and Logging Best Practices - Ordered by Complexity

Basic (Beginner):

• Avoidance of sensitive information disclosure in error responses, including system details, session identifiers, or account information.

• Use of error handlers that do not expose debugging or stack trace details.

• Implementation of generic error messages and custom error pages.

• Proper memory deallocation when error conditions occur.

• Logging of all authentication attempts, with emphasis on failed attempts.

• Logging of all access control failures.

• Logging of all input validation failures.

• Logging of all system exceptions.

Intermediate:

• Implementation of all cryptographic functions used to protect secrets on a trusted system (e.g., the server).

• Logging of all backend TLS connection failures.

• Logging of cryptographic module failures.

• Logging of all apparent tampering events, including unexpected state data changes.

• Use of cryptographic hash functions to validate log entry integrity.

• Prevention of untrusted data in log entries from executing as code in log viewing interfaces or software.

• Restriction of log access to authorized individuals only.

• Utilization of a centralized routine for all logging operations.

• Ensuring a mechanism exists for log analysis.

Advanced:

• Protection of master secrets from unauthorized access.

• Secure failure of cryptographic modules.

• Generation of random numbers, file names, GUIDs, and strings using an approved cryptographic module's random number generator for un-guessable values.

• Compliance of cryptographic modules with FIPS 140-2 or an equivalent standard.

• Establishment and utilization of a policy and process for cryptographic key management.

• Denial of access by default in error handling logic associated with security controls.

• Implementation of logging controls on a trusted system (e.g., the server).

• Ensuring logs contain important log event data.

• Logging of attempts to connect using invalid or expired session tokens.

• Logging of all administrative functions, particularly changes to security configuration settings.

List 1: Data Protection Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Implementation of least privilege, restricting users to only the necessary functionality, data, and system information required for their tasks.

• Encryption of highly sensitive stored information, such as authentication verification data, even on the server side, using well-vetted algorithms (refer to "Cryptographic Practices" for further guidance).

• Protection of all cached or temporary copies of sensitive data stored on the server from unauthorized access, with purging of temporary working files once no longer required.

• Implementation of appropriate access controls for sensitive data stored on the server, including cached data, temporary files, and data restricted to specific system users.

• Protection of server-side source code from unauthorized downloads by users.

Moderate Relevance (Common Security Concerns):

• Avoidance of storing passwords, connection strings, or other sensitive information in clear text or non-cryptographically secure methods on the client side, including insecure formats like MS viewstate, Adobe Flash, or compiled code.

• Disabling of client-side caching on pages containing sensitive information, with the use of Cache-Control: no-store, and optionally "Pragma: no-cache" for backward compatibility with HTTP/1.0.

• Avoidance of including sensitive information in HTTP GET request parameters.

• Removal of comments in user-accessible production code that may disclose backend system details or other sensitive information.

Low Relevance (Edge Cases and Lesser-known Threats):

• Disabling of autocomplete features on forms expected to contain sensitive information, such as authentication forms.

• Support for the removal of sensitive data from the application when it is no longer required (e.g., personal information or financial data).

• Removal of unnecessary application and system documentation to prevent attackers from accessing useful information.

List 2: Data Protection Best Practices - Ordered by Complexity

Basic (Beginner):

• Avoidance of including sensitive information in HTTP GET request parameters.

• Removal of comments in user-accessible production code that may disclose backend system details or other sensitive information.

• Removal of unnecessary application and system documentation to prevent attackers from accessing useful information.

• Disabling of autocomplete features on forms expected to contain sensitive information, such as authentication forms.

Intermediate:

• Disabling of client-side caching on pages containing sensitive information, with the use of Cache-Control: no-store, and optionally "Pragma: no-cache" for backward compatibility with HTTP/1.0.

• Support for the removal of sensitive data from the application when it is no longer required (e.g., personal information or financial data).

• Avoidance of storing passwords, connection strings, or other sensitive information in clear text or non-cryptographically secure methods on the client side, including insecure formats like MS viewstate, Adobe Flash, or compiled code.

Advanced:

• Implementation of least privilege, restricting users to only the necessary functionality, data, and system information required for their tasks.

• Encryption of highly sensitive stored information, such as authentication verification data, even on the server side, using well-vetted algorithms (refer to "Cryptographic Practices" for further guidance).

• Protection of all cached or temporary copies of sensitive data stored on the server from unauthorized access, with purging of temporary working files once no longer required.

• Protection of server-side source code from unauthorized downloads by users.

• Implementation of appropriate access controls for sensitive data stored on the server, including cached data, temporary files, and data restricted to specific system users.

List 1: Database Security Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Use of strongly typed parameterized queries.

• Access to the database by the application using the lowest possible level of privilege.

• Use of secure credentials for database access.

• Storage of connection strings in a separate, encrypted configuration file on a trusted system, avoiding hardcoding within the application.

• Removal or modification of all default database administrative passwords, ensuring strong passwords/phrases or multi-factor authentication.

Moderate Relevance (Common Security Concerns):

• Utilization of input validation and output encoding, ensuring meta characters are properly handled, and prevention of database command execution if validation fails.

• Use of stored procedures to abstract data access, allowing the removal of direct permissions to base tables in the database.

• Disabling of default accounts that are not necessary for business requirements.

• Deactivation of unnecessary database functionality, such as unneeded stored procedures, services, or utility packages, and installation of only the required features (surface area reduction).

Low Relevance (Edge Cases and Lesser-known Threats):

• Ensuring that variables are strongly typed.

• Closure of database connections as soon as possible.

• Removal of unnecessary default vendor content, such as sample schemas.

• Connection to the database with distinct credentials for each trust level (e.g., user, read-only user, guest, administrators).

List 2: Database Security Best Practices - Ordered by Complexity

Basic (Beginner):

• Use of strongly typed parameterized queries.

• Ensuring that variables are strongly typed.

• Closure of database connections as soon as possible.

Intermediate:

• Access to the database by the application using the lowest possible level of privilege.

• Use of secure credentials for database access.

• Removal or modification of all default database administrative passwords, ensuring strong passwords/phrases or multi-factor authentication.

• Utilization of input validation and output encoding, ensuring meta characters are properly handled, and prevention of database command execution if validation fails.

• Removal of unnecessary default vendor content, such as sample schemas.

Advanced:

• Storage of connection strings in a separate, encrypted configuration file on a trusted system, avoiding hardcoding within the application.

• Use of stored procedures to abstract data access, allowing the removal of direct permissions to base tables in the database.

• Deactivation of unnecessary database functionality, such as unneeded stored procedures, services, or utility packages, and installation of only the required features (surface area reduction).

• Disabling of default accounts that are not necessary for business requirements.

• Connection to the database with distinct credentials for each trust level (e.g., user, read-only user, guest, administrators).

List 1: File and Memory Management Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Requirement of authentication before allowing file uploads.

• Limitation of uploadable file types to only those necessary for business purposes.

• Validation of uploaded files by checking file headers rather than file extensions alone.

• Prevention or restriction of file uploads that can be interpreted by the web server.

• Deactivation of execution privileges in file upload directories.

• Avoidance of passing user-supplied data into dynamic redirects, or ensuring only validated, relative path URLs are allowed.

• Avoidance of passing user-supplied data directly into dynamic include functions.

• Scanning of user-uploaded files for viruses and malware.

Moderate Relevance (Common Security Concerns):

• Separation of file storage from the application’s web context, with files stored on a content server or in a database.

• Use of a whitelist for referencing existing files, validating file names and types against expected values.

• Replacement of directory or file paths with index values mapped to predefined path lists.

• Ensuring that application files and resources are read-only.

• Safe uploading in UNIX through mounting the target file directory as a logical drive or using the chrooted environment.

Low Relevance (Edge Cases and Lesser-known Threats):

• Avoidance of sending absolute file paths to clients.

• Use of input and output control for untrusted data.

• Verification that buffers are as large as specified.

• Checking of buffer boundaries when functions are called in a loop, ensuring no writes beyond allocated space.

• Truncation of input strings to a reasonable length before using copy or concatenation functions.

• Awareness of potential non-termination of strings when using functions like strncpy(), especially when the destination buffer size matches the source buffer size.

• Explicit closure of resources, avoiding reliance on garbage collection (e.g., connection objects, file handles).

• Avoidance of known vulnerable functions (e.g., printf, strcat, strcpy).

• Proper freeing of allocated memory upon function completion and at all exit points.

• Use of non-executable stacks when available.

List 2: File and Memory Management Best Practices - Ordered by Complexity

Basic (Beginner):

• Avoidance of passing user-supplied data directly into dynamic include functions.

• Avoidance of sending absolute file paths to clients.

• Verification that buffers are as large as specified.

• Checking of buffer boundaries when functions are called in a loop, ensuring no writes beyond allocated space.

• Truncation of input strings to a reasonable length before using copy or concatenation functions.

• Explicit closure of resources, avoiding reliance on garbage collection (e.g., connection objects, file handles).

Intermediate:

• Requirement of authentication before allowing file uploads.

• Limitation of uploadable file types to only those necessary for business purposes.

• Validation of uploaded files by checking file headers rather than file extensions alone.

• Prevention or restriction of file uploads that can be interpreted by the web server.

• Use of input and output control for untrusted data.

• Use of a whitelist for referencing existing files, validating file names and types against expected values.

• Replacement of directory or file paths with index values mapped to predefined path lists.

• Ensuring that application files and resources are read-only.

• Awareness of potential non-termination of strings when using functions like strncpy(), especially when the destination buffer size matches the source buffer size.

Advanced:

• Deactivation of execution privileges in file upload directories.

• Separation of file storage from the application’s web context, with files stored on a content server or in a database.

• Safe uploading in UNIX through mounting the target file directory as a logical drive or using the chrooted environment.

• Avoidance of passing user-supplied data into dynamic redirects, or ensuring only validated, relative path URLs are allowed.

• Scanning of user-uploaded files for viruses and malware.

• Avoidance of known vulnerable functions (e.g., printf, strcat, strcpy).

• Proper freeing of allocated memory upon function completion and at all exit points.

• Use of non-executable stacks when available.

List 1: Communication Security Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Implementation of encryption for transmitting all sensitive information, including the use of TLS for protecting connections. Discrete encryption may supplement this for sensitive files or non-HTTP based connections. TLS certificates must be valid, associated with the correct domain name, unexpired, and installed with intermediate certificates when needed.

• Prevention of fallback to insecure connections upon TLS failure.

• Use of TLS for all content requiring authenticated access and other sensitive information.

• Application of TLS for connections to external systems that handle sensitive information or perform sensitive functions.

• TLS certificate validation (correct domain, unexpired, and with intermediate certificates)

Moderate Relevance (Common Security Concerns):

• Adoption of a single, standardized TLS implementation with proper configuration.

• Specification of character encodings for all connections.

Low Relevance (Edge Cases and Lesser-known Threats):

• Filtering of parameters containing sensitive information from HTTP referer headers when linking to external sites.

List 2: Communication Security Best Practices - Ordered by Complexity

Basic (Beginner):

• Filtering of parameters containing sensitive information from HTTP referer headers when linking to external sites.

• Specification of character encodings for all connections.

Intermediate:

• Use of TLS for all content requiring authenticated access and other sensitive information.

• Application of TLS for connections to external systems that handle sensitive information or perform sensitive functions.

• Adoption of a single, standardized TLS implementation with proper configuration.

Advanced:

• Implementation of encryption for transmitting all sensitive information, including the use of TLS for protecting connections. Discrete encryption may supplement this for sensitive files or non-HTTP based connections. TLS certificates must be valid, associated with the correct domain name, unexpired, and installed with intermediate certificates when needed.

• Prevention of fallback to insecure connections upon TLS failure.

• TLS certificate validation (correct domain, unexpired, and with intermediate certificates)

List 1: System Configuration Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Restriction of web server, process, and service accounts to the least privileges necessary.

• Secure failure handling when exceptions occur.

• Removal of unnecessary functionality and files.

• Assurance that servers, frameworks, and system components are running the latest approved versions.

• Application of all patches issued for the version in use across servers, frameworks, and system components.

• Removal of test code and any non-production functionality prior to deployment.

• Isolation of development environments from the production network, with access restricted to authorized development and test groups.

Moderate Relevance (Common Security Concerns):

• Disabling of unnecessary HTTP methods, such as WebDAV extensions, with well-vetted authentication mechanisms required if file-handling methods are needed.

• Deactivation of directory listings.

• Prevention of directory structure disclosure in the robots.txt file by placing directories not intended for public indexing into an isolated parent directory and disallowing the entire parent directory.

• Removal of unnecessary information from HTTP response headers, such as OS details, web server version, and application framework identifiers.

• Definition of supported HTTP methods, such as GET or POST, and consideration of their use across different application pages.

Low Relevance (Edge Cases and Lesser-known Threats):

• Configuration of both HTTP 1.0 and 1.1 to ensure similarity or proper understanding of any differences, especially regarding extended HTTP methods.

• Capability to output the security configuration store in a human-readable form for auditing purposes.

• Implementation of an asset management system for registering system components and software.

• Implementation of a software change control system to manage and document code changes in both development and production.

List 2: System Configuration Best Practices - Ordered by Complexity

Basic (Beginner):

• Removal of unnecessary functionality and files.

• Deactivation of directory listings.

• Removal of test code and any non-production functionality prior to deployment.

• Definition of supported HTTP methods, such as GET or POST, and consideration of their use across different application pages.

• Removal of unnecessary information from HTTP response headers, such as OS details, web server version, and application framework identifiers.

Intermediate:

• Restriction of web server, process, and service accounts to the least privileges necessary.

• Secure failure handling when exceptions occur.

• Assurance that servers, frameworks, and system components are running the latest approved versions.

• Application of all patches issued for the version in use across servers, frameworks, and system components.

• Disabling of unnecessary HTTP methods, such as WebDAV extensions, with well-vetted authentication mechanisms required if file-handling methods are needed.

• Prevention of directory structure disclosure in the robots.txt file by placing directories not intended for public indexing into an isolated parent directory and disallowing the entire parent directory.

Advanced:

• Isolation of development environments from the production network, with access restricted to authorized development and test groups.

• Configuration of both HTTP 1.0 and 1.1 to ensure similarity or proper understanding of any differences, especially regarding extended HTTP methods.

• Capability to output the security configuration store in a human-readable form for auditing purposes.

• Implementation of an asset management system for registering system components and software.

• Implementation of a software change control system to manage and document code changes in both development and production.

List 1: Cloud Security Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Implementation of strong identity and access management (IAM) controls to enforce least privilege and limit access to cloud resources.

• Encryption of sensitive data both in transit and at rest using industry-standard encryption protocols.

• Regular monitoring and auditing of cloud environments for unusual activity and potential security incidents.

• Implementation of multi-factor authentication (MFA) for all user accounts, especially privileged accounts.

• Application of security patches and updates to cloud infrastructure, operating systems, and applications.

• Use of cloud provider-native security services (e.g., firewalls, DDoS protection, key management) to secure cloud environments.

Moderate Relevance (Common Security Concerns):

• Establishment of strong backup and disaster recovery plans for critical cloud-based data and applications.

• Ensuring proper network segmentation in cloud environments to isolate sensitive resources.

• Regular review and audit of third-party cloud service providers' security practices and certifications.

• Monitoring and securing API endpoints to prevent unauthorized access or abuse.

Low Relevance (Edge Cases and Lesser-known Threats):

• Implementation of data loss prevention (DLP) solutions to detect and prevent unauthorized sharing of sensitive information.

• Conducting regular penetration testing of the cloud environment to identify vulnerabilities.

• Implementation of container and serverless security best practices for microservices-based cloud deployments.

• Continuous training and awareness programs for cloud users and administrators to prevent phishing and social engineering attacks.

• Regular review of cloud service-level agreements (SLAs) to ensure compliance with security and privacy requirements.

List 2: Cloud Security Best Practices - Ordered by Complexity

Basic (Beginner):

• Implementation of multi-factor authentication (MFA) for all user accounts, especially privileged accounts.

• Encryption of sensitive data both in transit and at rest using industry-standard encryption protocols.

• Application of security patches and updates to cloud infrastructure, operating systems, and applications.

• Establishment of strong backup and disaster recovery plans for critical cloud-based data and applications.

• Continuous training and awareness programs for cloud users and administrators to prevent phishing and social engineering attacks.

Intermediate:

• Implementation of strong identity and access management (IAM) controls to enforce least privilege and limit access to cloud resources.

• Regular monitoring and auditing of cloud environments for unusual activity and potential security incidents.

• Use of cloud provider-native security services (e.g., firewalls, DDoS protection, key management) to secure cloud environments.

• Ensuring proper network segmentation in cloud environments to isolate sensitive resources.

• Regular review and audit of third-party cloud service providers' security practices and certifications.

Advanced:

• Monitoring and securing API endpoints to prevent unauthorized access or abuse.

• Implementation of data loss prevention (DLP) solutions to detect and prevent unauthorized sharing of sensitive information.

• Conducting regular penetration testing of the cloud environment to identify vulnerabilities.

• Implementation of container and serverless security best practices for microservices-based cloud deployments.

• Regular review of cloud service-level agreements (SLAs) to ensure compliance with security and privacy requirements.

List 1: Mobile Application Security Best Practices - Ordered by Relevance

High-Relevance (Critical Threat Mitigation):

• Implementation of strong authentication and authorization mechanisms, such as multi-factor authentication (MFA) and secure token management.

• Encryption of sensitive data both in transit and at rest using strong encryption standards.

• Regularly updating the mobile app and its dependencies to apply security patches and address known vulnerabilities.

• Protection of sensitive user data, including personally identifiable information (PII), by adhering to privacy regulations and minimizing data collection.

• Secure storage of sensitive information, such as passwords and tokens, using device-provided secure storage mechanisms (e.g., Keychain for iOS, Keystore for Android).

Moderate Relevance (Common Security Concerns):

• Implementation of secure coding practices to prevent common vulnerabilities such as SQL injection, buffer overflows, and cross-site scripting (XSS).

• Secure communication between the mobile app and backend services, ensuring SSL/TLS is properly configured.

• Use of secure APIs, ensuring proper validation and authorization for accessing backend services.

• Protection against reverse engineering through code obfuscation and securing the app's source code.

• Regular security testing and vulnerability assessments, including penetration testing.

Low Relevance (Edge Cases and Lesser-known Threats):

• Prevention of data leakage by restricting app permissions to only those necessary for functionality.

• Implementation of tamper detection mechanisms, such as checking for jailbroken/rooted devices.

• Monitoring of the mobile app for suspicious activity and potential security incidents.

• Use of in-app security tools (e.g., runtime application self-protection) to monitor and defend against threats in real-time.

• Proper management and revocation of user sessions and tokens to prevent unauthorized access to services.

List 2: Mobile Application Security Best Practices - Ordered by Complexity

Basic (Beginner):

• Regularly updating the mobile app and its dependencies to apply security patches and address known vulnerabilities.

• Encryption of sensitive data both in transit and at rest using strong encryption standards.

• Secure storage of sensitive information, such as passwords and tokens, using device-provided secure storage mechanisms (e.g., Keychain for iOS, Keystore for Android).

• Implementation of strong authentication and authorization mechanisms, such as multi-factor authentication (MFA) and secure token management.

• Protection of sensitive user data, including personally identifiable information (PII), by adhering to privacy regulations and minimizing data collection.

Intermediate:

• Implementation of secure coding practices to prevent common vulnerabilities such as SQL injection, buffer overflows, and cross-site scripting (XSS).

• Secure communication between the mobile app and backend services, ensuring SSL/TLS is properly configured.

• Use of secure APIs, ensuring proper validation and authorization for accessing backend services.

• Protection against reverse engineering through code obfuscation and securing the app's source code.

• Prevention of data leakage by restricting app permissions to only those necessary for functionality.

Advanced:

• Regular security testing and vulnerability assessments, including penetration testing.

• Monitoring of the mobile app for suspicious activity and potential security incidents.

• Implementation of tamper detection mechanisms, such as checking for jailbroken/rooted devices.

• Use of in-app security tools (e.g., runtime application self-protection) to monitor and defend against threats in real-time.

• Proper management and revocation of user sessions and tokens to prevent unauthorized access to services.

• Implement InMemoryTodoService: Create a simple in-memory storage using Map<Long, Todo>. Implement methods: create, findAll, findById, update, delete.

• Implement GET /todos: Add a controller method that returns the full list of todos as JSON.

• Implement GET /todos/{id}: Add a controller method that returns a todo by id, or 404 if not found.

• Implement PUT /todos/{id}: Add a controller method that updates an existing todo. Return 404 if not found.

• Implement POST /todos: Add a controller method that accepts JSON payload {title} and creates a new todo.

• Implement DELETE /todos/{id}: Add a controller method that deletes a todo by id. Return 204 on success, 404 if not found.

• Implement UserValidator: Add isValid(User) to enforce age >= 18 and a basic email regex; return true only when both checks pass.

• Implement readUsers: In UserJsonProcessor.readUsers(Path input), parse a JSON array into List<User> using Jackson; throw an IOException if the file is missing.

• Implement splitValidInvalid: In UserJsonProcessor.splitValidInvalid(List<User>), partition users into valid and invalid lists using UserValidator; return a ValidationSplit(valid, invalid).

• Implement writeUsers: In UserJsonProcessor.writeUsers(List<User>, Path output), ensure the parent directory exists and write the list as a JSON array (pretty-printed).

• Wire the pipeline (optional run): In Application.main, read src/test/resources/users.json, split valid/invalid, and write outputs to data/valid.json and data/errors.json; print a short summary.

• Make the tests pass: Run UserJsonProcessorTest; ensure counts match (valid=2, invalid=2 for the sample), files are created and non-empty, and edge cases (blank/null email, age < 18) are handled.

• Implement PasswordHasher: Add SHA-256 hashing that returns a hex string; never store raw passwords.

• Implement InMemoryUserStore: Use Map<Long,User> and Map<String,User> to store users; implement findByEmail and saveNew with auto-incremented IDs.

• Implement InMemoryTokenStore: Issue random UUID tokens, map token → userId, implement resolveUserId and revoke.

• Implement POST /register: Accept {email, password, displayName}; create user with hashed password; on success return 201 Created with Location: /users/{id} and safe user JSON; if email exists return 409 Conflict.

• Implement POST /login: Accept {email, password}; on valid credentials return 200 OK with {"token":"..."}; on failure return 401 Unauthorized.

• Implement GET /profile: Require header Authorization: Bearer <token>; return 200 OK with safe user JSON; if token missing/invalid return 401 Unauthorized.

• Implement POST /logout: Accept bearer token; revoke it and return 204 No Content (idempotent).

In this lab, you will design and implement a simple relational database for managing users and their orders.

You’ll start by creating the core tables, establish one-to-many relationships, and then write SQL queries to explore and analyze the data.

By the end of this lab, you’ll have practiced key relational database concepts: primary keys, foreign keys, joins, filtering, and aggregate functions.

This lab simulates a real-world business scenario where each user can have multiple orders, and we need to analyze their purchase activity efficiently.

• Create Database and Tables

  • Create a new database named user_orders_lab.

  • Create users and orders tables with proper primary and foreign keys.

• Insert Initial Data

  • Populate both tables with at least 3–4 users and 5–6 orders.

  • Ensure that at least one user has multiple orders.

• Display and Inspect Data

  • Run SELECT * queries to verify that data has been inserted correctly.

• Join Data Across Tables

  • Write a JOIN query to display each order along with the corresponding user name.

• Aggregation Analysis

  • Calculate total spending per user using SUM and GROUP BY.

  • Order the results by total amount descending.

• Advanced Querying

  • Find users with more than one order (HAVING COUNT > 1).

  • Identify the most expensive order using a subquery.

In this lab, you will analyze a dataset of users and their orders to uncover meaningful business insights using SQL aggregate functions and subqueries.

You’ll calculate totals, averages, and counts, identify top customers, and use nested SELECT statements to compare individual data points to group-wide metrics.

By the end of this lab, you’ll be confident in using COUNT, SUM, AVG, MIN, MAX, GROUP BY, HAVING, and subqueries — all essential tools for data-driven decision-making in real-world projects.

• Explore the Dataset: Display all records from both tables using SELECT *.

• Basic Aggregations: Use COUNT, AVG, MIN, MAX to get overall order statistics.

• User-Level Analysis: Calculate total and average spending per user using GROUP BY.

• Country-Level Report: Group by country to see total orders and revenue per region.

• Filtering with HAVING: Show only users whose total spending is above 500.

• Subqueries for Comparison: Find users whose average order value is greater than the overall average order value.

• Nested Subqueries: Find the largest order per country using a correlated subquery.

In this lab, you’ll work with a company database that includes employees, departments, and salaries.

You will learn how to filter and sort records using various SQL clauses (WHERE, LIKE, BETWEEN, IN, ORDER BY, LIMIT) and explore different types of joins (INNER, LEFT, RIGHT, CROSS) to connect related tables.

By the end of this lab, you’ll know how to query complex datasets effectively, extract relevant information, and analyze relationships between employees and their departments.

These are real-world skills used daily by data analysts, engineers, and backend developers working with relational databases.

• Filter by Salary and Hire Date: Display employees earning more than 80,000 who were hired before 2021.

• Pattern Matching with LIKE: Find employees whose last name starts with “W” or whose position contains the word “Engineer”.

• Filtering with IN and BETWEEN: Show employees from Engineering or Finance earning between 75,000 and 125,000.

• Sorting and Limiting Results: List the top 3 highest-paid employees.

• INNER JOIN Practice: Display all employees with their department names using INNER JOIN.

• LEFT and RIGHT JOIN Comparison: Compare LEFT JOIN and RIGHT JOIN results — notice the difference in unmatched records.

• CROSS JOIN Exploration: Generate all combinations of employees and departments, limited to 10 rows for readability.