Starting Letter: C

The CCPA applies to for-profit businesses that collect personal information from California residents and meet at least one of the following criteria:

• Generate more than $25 million in annual gross revenue; or

• Buy, receive, sell, or share the personal information of 100,000 or more consumers or households annually; or

• Derive 50% or more of their annual revenue from selling or sharing personal information

The law applies regardless of where the business is located, provided it meets these thresholds and processes the personal data of California residents.

CCPA obligations also extend to:

• Service providers

• Contractors

• Third parties that process personal data on behalf of a business.

Under the CCPA, personal information is broadly defined as any information that identifies, relates to, describes, or could reasonably be linked to a particular consumer or household.

Examples include:

• Names and contact details

• Email addresses

• IP addresses

• Device identifiers

• Geolocation data

• Purchase history

• Internet activity (e.g., browsing behavior)

• Financial information

This broad definition reflects the realities of modern digital tracking and data collection.

The CCPA grants California residents several important rights over their personal information.

1. Right to Know

Consumers have the right to request that businesses disclose:

• Categories of personal information collected

• Specific pieces of personal information held

• Sources of the data

• Business or commercial purposes for collection

• Categories of third parties with whom data is shared

2. Right to Delete

Consumers can request that businesses delete personal information collected from them, subject to certain legal exceptions.

Businesses must also instruct service providers and contractors to delete the data where applicable.

3. Right to Opt-Out of Sale and Sharing

Consumers have the right to opt out of:

• The sale of their personal information

• The sharing of personal information for cross-context behavioral advertising

Businesses must provide a clear and accessible “Do Not Sell or Share My Personal Information” mechanism.

4. Right to Non-Discrimination

Businesses may not discriminate against consumers for exercising their CCPA rights. This includes:

• Charging different prices

• Denying goods or services

• Providing a lower level of service

However, certain financial incentive programs are permitted if they are transparently disclosed and compliant.

5. Additional Rights Introduced by CPRA

The California Privacy Rights Act (CPRA), which amends the CCPA, introduces additional rights, including:

• The right to correct inaccurate personal information

• The right to limit the use and disclosure of sensitive personal information

These enhancements significantly expand the original scope of the CCPA.

Organizations subject to the CCPA must implement several key compliance measures.

1. Notice at Collection

Businesses must provide notice at or before collecting personal information, including:

• Categories of data collected

• Purposes for collection

• Whether the data will be sold or shared

This is typically provided through a “notice at collection” and a privacy policy.

2. Privacy Policy Requirements

Businesses must maintain a clear, accessible, and up-to-date privacy policy that includes:

• Description of consumer rights

• Instructions on how to exercise those rights

• Categories of personal information collected, used, sold, or shared

• Retention practices or criteria used to determine retention

Privacy policies must be reviewed and updated at least every 12 months.

3. Consumer Request Handling

Businesses must establish processes to:

• Receive and verify consumer requests

• Respond within 45 days (with limited extensions)

• Deliver requested data securely

Organizations must also maintain records of requests and responses, particularly if handling large volumes of data.

4. Methods for Submitting Requests

Businesses must provide at least two methods for consumers to submit requests, such as:

• A web form

• A toll-free telephone number

If the business operates online, it must include a clear opt-out link for selling or sharing personal information.

5. Data Security Requirements

Businesses must implement reasonable security procedures and practices appropriate to the nature of the data. This includes protecting:

• Web applications

• APIs

• Databases

• Client-side applications and browser environments

• Third-party integrations

Failure to implement adequate security measures may result in liability, especially in the event of a data breach.

6. Third-Party and Service Provider Management

Businesses must establish contracts with:

• Service providers

• Contractors

• Third parties

These contracts must restrict how personal information is:

• Used

• Retained

• Disclosed

Businesses remain responsible for ensuring that third parties process data in compliance with the law.

7. Recordkeeping and Accountability

Businesses handling large volumes of personal data must:

• Maintain records of consumer requests and responses for at least 24 months

• Be able to demonstrate compliance with the CCPA

This supports regulatory audits and enforcement actions.

CCPA compliance requires organizations to address modern security risks across the entire data ecosystem.

Personal information may be exposed through:

• Client-side vulnerabilities

• Third-party scripts

• API misconfigurations

• Browser-based attacks

• Insecure integrations

Organizations must implement comprehensive application security strategies to protect personal data throughout its lifecycle—from collection to storage and processing.

The California Privacy Rights Act (CPRA), effective January 1, 2023, significantly expands the CCPA by:

• Introducing Sensitive Personal Information protections

• Expanding opt-out rights to include data sharing

• Adding the right to correct personal information

• Strengthening data minimization and retention requirements

• Creating the California Privacy Protection Agency (CPPA)

• Enhancing enforcement and compliance obligations

Together, the CCPA and CPRA form a more comprehensive privacy framework for California.

The California Consumer Privacy Act (CCPA) represents a foundational shift in U.S. privacy law, empowering consumers and holding businesses accountable for how personal data is handled.

With the enhancements introduced by CPRA, organizations must adopt comprehensive legal, operational, and technical measures to ensure compliance.

By implementing strong privacy and security practices, businesses can not only meet regulatory requirements but also build trust, improve resilience, and responsibly manage personal data in the modern digital landscape.

The CPRA was approved by California voters in November 2020 through Proposition 24. Rather than replacing the CCPA, the CPRA amends and expands it to address evolving privacy risks, technological advancements, and gaps identified in the original law.

The law became effective on January 1, 2023, with enforcement beginning on July 1, 2023.

One of the most important changes introduced by CPRA is the creation of a dedicated privacy regulator, the California Privacy Protection Agency (CPPA), which shares enforcement authority with the California Attorney General.

The CPRA’s primary goals are to:

• Strengthen consumer privacy rights

• Increase transparency in data processing

• Improve accountability for businesses handling personal data

• Require stronger data security and risk management practices

CPRA applies to for-profit businesses that operate in California and meet at least one of the following criteria:

• Generate more than $25 million in annual gross revenue; or

• Buy, sell, or share personal information of 100,000 or more California residents or households annually; or

• Derive 50% or more of their annual revenue from selling or sharing personal information
  
  

The law also applies to service providers, contractors, and third parties that process personal data on behalf of regulated businesses.

Importantly, CPRA expands regulation beyond the “sale” of personal data to include “sharing,” which covers the disclosure of personal information for cross-context behavioral advertising, even when no monetary exchange occurs.

The CPRA significantly expands consumer rights and provides individuals with greater control over their personal information.

1. Right to Know

Consumers have the right to request detailed information about:

• What personal information is collected

• The sources of the data

• The purpose of collection

• How the information is used

• Whether the data is sold or shared

• Categories of third parties receiving the data
  
  

2. Right to Delete

Consumers may request that businesses delete personal information collected about them, subject to certain legal and operational exceptions.

Businesses must also notify service providers, contractors, and third parties to delete the information where applicable.

3. Right to Correct

CPRA introduces the right for consumers to request the correction of inaccurate personal information maintained by businesses.

Organizations must implement reasonable procedures to verify and correct data upon request.

4. Right to Opt-Out of Sale and Sharing

Consumers have the right to opt out of:

• The sale of their personal information

• The sharing of personal information for cross-context behavioral advertising
  
  

Businesses must provide clear and accessible mechanisms to exercise this right.

5. Right to Limit Use and Disclosure of Sensitive Personal Information

Consumers have the right to restrict how businesses use and disclose Sensitive Personal Information (SPI), limiting its use to necessary purposes such as providing requested services.

6. Right to Data Portability

Consumers may request access to their personal information in a structured, commonly used, and machine-readable format, enabling easy transfer between organizations.

7. Rights Related to Automated Decision-Making

CPRA authorizes regulations that provide consumers with rights related to automated decision-making, including profiling and automated processing that significantly affects individuals.

Businesses may be required to provide transparency and opt-out options regarding automated decision-making systems.

CPRA introduces a new category of highly sensitive data called Sensitive Personal Information (SPI), which includes:

• Social Security numbers

• Driver’s license and passport numbers

• Financial account and payment information

• Precise geolocation data

• Racial or ethnic origin

• Religious beliefs

• Health information

• Biometric information

• Sexual orientation

• Contents of private communications
  
  

Businesses must provide consumers with the ability to limit how this information is used and disclosed.

CPRA imposes significant compliance obligations on businesses.

1. Transparency Requirements

Businesses must provide clear and accessible privacy notices explaining:

• What data is collected

• Why it is collected

• How it is used

• Whether it is sold or shared

• How long it is retained
  
  

Organizations must disclose retention periods or explain how retention periods are determined.

2. Data Minimization and Purpose Limitation

Businesses may only collect, use, and retain personal information that is reasonably necessary and proportionate to the disclosed purpose.

Data cannot be used for unrelated purposes without additional notice and consent.

3. Data Retention Limitations

Businesses must not retain personal information longer than necessary to fulfill their stated purpose.

Retention policies must be documented and enforced.

4. Security Safeguards

CPRA requires businesses to implement reasonable security procedures and practices to protect personal information from unauthorized access, disclosure, or loss. This includes securing:

• Web applications

• APIs

• Client-side applications

• Cloud infrastructure

• Internal systems
  
  

Failure to implement adequate security controls may result in enforcement actions and civil liability.

5. Risk Assessments and Cybersecurity Audits

CPRA authorizes the CPPA to require businesses engaged in high-risk data processing to conduct:

• Privacy risk assessments

• Cybersecurity audits
  
  

These assessments help identify and mitigate risks to consumer data.

6. Third-Party and Contractor Requirements

CPRA creates distinct legal categories for:

• Service providers

• Contractors

• Third parties
  
  

Businesses must establish written contracts requiring these entities to protect personal data and comply with CPRA requirements.

Organizations remain accountable for how third parties handle consumer information.

7. Consumer Request Handling

Businesses must implement processes to:

• Receive consumer privacy requests

• Verify identity

• Respond within required timelines

• Maintain records of requests and responses
  
  

Employee training on privacy compliance is also required.

CPRA enforcement is conducted by:

• California Privacy Protection Agency (CPPA)

• California Attorney General
  
  

Violations may result in penalties of:

• Up to $2,500 per violation

• Up to $7,500 per intentional violation

• Up to $7,500 per violation involving minors under 16
  
  

Each affected consumer may count as a separate violation, significantly increasing potential penalties.

Consumers also have a private right of action for certain data breaches involving inadequate security.

CPRA emphasizes the importance of protecting personal data across modern digital environments.

Compliance requires securing not only backend systems but also:

• Web browsers and client-side applications

• JavaScript environments

• APIs and integrations

• Third-party scripts
  
  

Security vulnerabilities in client-side applications can expose personal data even when backend systems are secure.

Organizations must implement comprehensive application security strategies to protect personal information throughout its lifecycle.

CPRA strengthens and expands CCPA in several important ways:

• Establishes the California Privacy Protection Agency (CPPA)

• Introduces Sensitive Personal Information protections

• Adds the right to correct personal information

• Expands opt-out rights to include data sharing

• Strengthens requirements for data minimization and retention

• Adds risk assessment and cybersecurity audit requirements

• Increases accountability for third parties
  
  

Enhances enforcement mechanisms and penalties.

The California Privacy Rights Act (CPRA) represents a major advancement in U.S. privacy law. By strengthening consumer rights, expanding business obligations, and establishing a dedicated enforcement agency, CPRA creates a more robust framework for protecting personal information.

Organizations must adopt comprehensive privacy, security, and governance practices to comply with CPRA requirements and protect consumer data effectively.

As privacy regulations continue to evolve, CPRA sets an important benchmark for privacy protection and data accountability in the digital economy.

In modern times, web apps and pages load an average of more than 30 scripts from third-parties at runtime on the user’s browser. Naturally, the potential for compromise via that user’s device has been growing exponentially.

When relying on third-party code that’s integrated into the user experience almost in real-time, it considerably opens the door for an attack to happen.

The organization that owns and operates the website that’s being viewed by the user does not have control over the code or visibility into how the code is behaving at runtime. And, considering the rise of online shopping, as more transactions are made online and more sensitive data transverses networks as a result, the greater the incentive and opportunities for client-side attacks.

Furthermore, client-side JavaScript can easily be targeted since anyone can debug the code and even modify it at runtime. This becomes problematic because companies store important business logic on the client-side, which is often unavoidable due to the absence of a back-end or the need to avoid performance losses.

Companies’ proprietary algorithms and logic end up running in an adversarial environment, which opens the door to a series of attacks, including automated abuse, piracy, intellectual property theft, and data exfiltration. And unfortunately, client-side attacks take longer to be detected.

Considering the risks of Magecart or Web Supply Chain attacks, regulators have been insisting on strict regulations to ensure that businesses protect themselves and their sensitive data.

Client-side attacks occur when a malicious actor takes advantage of security weaknesses or vulnerabilities that exist on the end-user's device, whether it is a mobile device, a browser, or any other client application.

Because there’s so much sensitive data being handled on the client side nowadays, including personally identifiable information (PII), payment data, protected health information, etc., client-side attacks are considered one of the most dangerous types of security threats.

Because data handled on the client-side must be unencrypted, this also presents attackers with a window of opportunity to access and potentially leak this data before it is encrypted and sent over the network to be stored at a secure server.

Client-side attack examples

Some of the most relevant examples of client-side attacks include Magecart web skimming attacks, where malicious actors tamper with client-side payment forms to collect credit card information and send it to their own servers, and customer hijacking, where the user is diverted to another page.

The common goal of this method is to steal valuable information from a webpage, computer, or server, especially sensitive information such as credit card numbers. Enterprises like British Airways and Ticketmaster are two of the thousands of victims.

There are available several key frameworks that provide information about client-side vulnerabilities.

OWASP

One of the most popular frameworks is OWASP, the Open Web Application Security Project. It is a non-profit entity with international recognition, acting with a focus on collaboration to strengthen software security worldwide. OWASP maintains a list of the 10 most dangerous web application security flaws, along with the most effective methods for dealing with them.

Cybersecurity Framework from NIST

The Cybersecurity Framework from the US National Institute of Standards and Technology (NIST) is also very well-known. Both of these frameworks highlight the importance of ensuring the integrity of both first- and third-party code running on the client-side of web applications.

Regulatory requirements

In addition to these guidelines, there are also regulatory requirements that mandate client-side security, especially in e-commerce environments. The most important requirement is the Payment Card Industry Data Security Standard (PCI DSS), which just issued version 4.0.

PCI DSS mandates the monitoring and maintenance of an inventory of all code on a website’s payment pages, as well as the deployment of a tamper-detection mechanism that prevents the introduction of credit card-skimming code to payment pages.

Considering the dynamic nature of the web and JavaScript itself, there are several security aspects that must be taken into consideration to address client-side vulnerabilities.

1. Real-time monitoring

One of the best ways to guarantee full visibility and control on the client-side is to implement real-time monitoring.

You need to be able to detect, at any time, if there is any unauthorized script activity on your website.

To minimize the risk and the attack surface, you want to receive alerts when that is happening, as well as, of course, be able to act immediately and block or deactivate any malicious script.

2. Get visibility into third-party scripts

Additionally, it’s also recommended that you are fully aware of all the third-party scripts that are present on your website.

This might come from marketing or analytic tools that are broadly used on most websites. For this, it’s very helpful to maintain a dynamic inventory of all the scripts present on your website, including first-party and third-party code.

It is also one of the requirements mandated by version 4.0 of PCI DSS, which mandates that e-commerce businesses maintain a full inventory of every script on their payment page.

3. Other client-side attack prevention strategies

There are also other important methods that should be considered:

• First, regularly update and patch all the software and apps associated with your website;
  
  

• Beyond that, you should use monitoring and inspection technology that alerts in case of any unauthorized script activity. This should include a detection capability, scanning for anomalies, intrusions, or unknown threats;
  
  

• Content Security Policies (CSPs) can help detect and mitigate certain types of attacks. They provide an extra layer of protection but they aren’t enough by themselves: you should also be aware of the shortcomings of CSPs, in that (a) they can be bypassed if they use static whitelists and (b) they lack granularity, relying on a binary “block or allow” approach to third-party access, which fails to address issues such as “allow this unless…”;
  
  

• Split front-end applications into smaller components, e.g. public-facing, authenticated, and admin, so as to compartmentalize them and thereby reduce potential blast radiuses;
  
  

• Store sensitive website data in a dedicated meta field and keep API keys hidden from public view;
  
  

• Use SSL certificates for all websites and keep them up-to-date;
  
  

• Exercise extreme caution in the selection and implementation of third and fourth-party scripts (i.e. those that a third-party supplier itself sources from elsewhere);
  
  

• Maintain a dynamic inventory of all website scripts, including third-party and first-party;
  
  

• Monitor in real-time for any services attempting to access and leak sensitive data on the website;
  
  

• Adopt a proactive approach to client-side security, restricting the behaviors of website scripts to prevent them from tampering with forms and/or leaking sensitive data;
  
  

• Protect first-party JavaScript from reverse engineering and tampering attempts, both statically and at runtime.

Jscrambler Code Integrity uses obfuscation techniques, code locks, and self-defensive features to completely protect JavaScript code and block attackers from debugging the code.

This is a best practice and an OWASP recommendation for Mobile Applications that Jscrambler enables for JavaScript-based applications, whether running on a mobile device, web browser, or server-side.

The client-side is the no man's land of cybersecurity, with vulnerabilities, risks, threats, and opportunities for businesses but also for malicious actors.

What happens in the users' browsers is a silent war for users’ sensitive information between hackers and businesses, especially in the payment industry for payment card data. In e-commerce and online retailers, malicious actors moved from attacking a merchant's infrastructure to skimming payment card data from the users' browsers.

Client-side security, client-side attacks, and client-side vulnerabilities highlight the potential security breaches and incidents that may occur in the users' devices rather than on the business (server side) or between the two. Most of the top US websites are susceptible to client-side attacks.

In summary, modern web applications' use of third-party code expands attack surfaces.

Almost 50% of the Internet traffic comes from a web browser. The web browser interprets and runs this code to deliver the experience when the user accesses a website.

A market study by Statista shows Google Chrome to be the leading browser in the browser market share, with 61.80% of all users preferring it. Safari follows with 24.36%, with Edge, Firefox, and other browsers making up the remainder of the list.

Almost 50% of the Internet traffic comes from a web browser. The web browser interprets and runs this code to deliver the experience when the user accesses a website.

A market study by Statista shows Google Chrome to be the leading browser in the browser market share, with 61.80% of all users preferring it. Safari follows with 24.36%, with Edge, Firefox, and other browsers making up the remainder of the list.

Client-side vulnerabilities and web page protection in JavaScript go hand-in-hand when the concern is client-side security.

JavaScript security threats and risks are real. Moreover, JavaScript may represent a security weakness for businesses when the source code comes from third-party providers, for example.

First-party JavaScript

The code an organization generates may have been secure when written. However, the code may have been tampered with after it went into production or reverse-engineered by malicious actors.

A platform is requested as prescribed by the Open Web Application Security Project (OWASP) in its recommendations for keeping applications secure to ensure code integrity.

Third-party JavaScript

JavaScript code originating from third-party sources poses a significant risk because it has all the same privileges as first-party JavaScript code.

Since there are no default security settings for third-party JavaScript, the organization that operates the website or app pulling in that code is responsible for enforcing security and continuous monitoring.

Use of Forms and Secure Form Data

More than 90% of websites use forms to collect users’ personal information. Therefore, businesses must be committed to preventing breaches.

On average, the personal information collected has a high exposure: more than 15 third-party domains, expanding the risk of unauthorized access to data and script misbehaviors.

Client-side attacks have increased in cost and scale as companies expand their investments in the end-user digital experience.

From Jscramblers’ experience, we give three fundamentals to start improvising the client-side security of your applications:

1. Identify all third-party JavaScripts running on your web applications and website;

2. Understand what these third-party JavaScripts are doing and why;

3. Define which scripts are allowed to access data in forms on payment pages and block ones that should not from doing so.
   
   

Web applications load an average of 20+ third-party scripts as a part of the digital user experience. Additionally, a recent survey showed that 99% of security professionals reported their website uses at least one third-party script. 

By not developing a client-side security strategy and approach, security teams allow third-party code libraries to run amok on their servers.

The relevance of third-party scripts for users’ digital experience creates a JavaScript supply chain, and the lack of client-side security measures generates potential vulnerabilities to a software supply chain implemented almost in real-time on user’s devices. That said:

• For businesses that accept online payments, user’s browsers may be facing a silent war. 

• Website forms are open windows for data breaches.

• It is urgent to control third-party script behaviors on the client side, including tracking pixels and chatbots. 

Based on client-side weaknesses, hackers use different client-side attack methodologies to exploit vulnerabilities on the client-side of applications, frequently in the form of data exfiltration and content injections.

Data Exfiltration

Web Skimming/ Magecart Attack

Magecart attack technique involves inserting code, usually into payment pages, where it acts as an online credit card skimmer, pulling the personal information and payment card details of anyone unlucky enough to engage with it. Magecart attacks may also involve attacking a victim’s web services supply chain.

Data Leakage

Web apps integrate a mix of third-party services to ensure personalized user experiences. However, client-side attackers can target these services and add-ons to inject malicious code and launch supply chain attacks. Data leakage can also occur from a misconfigured legitimate third party. For example, a tracking pixel can originate data leakages, jeopardizing user security and privacy.

The consequence is the access to sensitive information they can leak without the knowledge of users or companies.

Content injection attacks 

This client-side attack technique sees attackers inserting malicious content that will appear to the end-user.

Cross-Site Scripting

Cross-site scripting (XSS) is one of the most common attack vectors regularly featured on the OWASP Top 10 Vulnerabilities list.

XSS involves the injection of malicious code into website content.

• Constantly patch and update all software and applications associated with the website.
  
  

• Monitor regularly script behaviors and web pages for changes.
  
  

• Employ ongoing monitoring with a client-side security solution designed to alert to unauthorized web application script activity.
  
  

• Be cautious and demanding when selecting and implementing third- and fourth-party scripts.

In 2023, Jscrambler received the Gold Place in Client-Side Security in the Cybersecurity Excellence Awards. See why:

1. Webpage Integrity

The Webpage Integrity (WPI) solution offers functionalities to protect customers against sensitive data leaks and unwanted changes that may harm their company’s reputation and business.

Webpage Integrity has already monitored over 40.3 million user sessions and blocked over 60.2 million data access attempts by third-party vendors. The continuous monitoring and proactive blocking of JavaScript running in the browser prevent these vendors from potentially accessing sensitive credit card data.

WPI allows organizations to understand all the scripts loaded onto each of their websites and the potential risks associated.

2. Code Integrity

The Code Integrity solution offers a runtime protection solution that protects web applications against runtime attacks.

This mature solution to protect the application code combines anti-debugging and anti-tampering techniques alongside other self-defensive capabilities, providing active protection for JavaScript applications.

Combining both techniques with code polymorphic obfuscation makes it impossible for an attacker to tamper with the web app.

Session cookies, also known as transient cookies, are temporary and are used to track the user's session on a website. They are stored in temporary memory and not retained after the browser is closed, and also they do not contain an expiration date and are designed to maintain state within a session, such as user login status, shopping cart contents, or form inputs.

Session cookies should be protected with the Secure and HttpOnly attributes to prevent interception and access by malicious scripts.

Persistent cookies, or stored cookies, remain on the user's device between sessions until they expire or are deleted by the user, and are used for remembering login information, and user preferences, and tracking user behavior across multiple sessions.

Persistent cookies must include an expiration date (specified via the Max-Age or Expires attribute), and their lifespan should be carefully considered to balance convenience with security. To safeguard these cookies, the Secure, HttpOnly, and SameSite attributes should be used to protect against unauthorized access and CSRF attacks. Additionally, sensitive data should never be stored directly in cookies, even if encrypted.

Secure cookies are specifically designed to enhance security throughout the transmission only over secure HTTPS connections.

The Secure attribute prevents the cookie from being sent over an unencrypted HTTP connection, mitigating the risk of interception by attackers. Keep in mind that this attribute is important for all cookies that are used in secure transactions or contain sensitive information.

The HttpOnly attribute restricts access to the cookie from client-side scripts, offering protection against XSS attacks. With the cookie inaccessible to JavaScript, this attribute helps prevent attackers from stealing the cookie through script injection. It's a basic security measure for all cookies, particularly those related to authentication and session management.

Third-party cookies are created by domains other than the one the user is currently visiting, often used for advertising and tracking purposes across websites. These cookies have been a privacy concern, leading to increased regulation and browser restrictions.

Developers and advertisers must navigate evolving privacy laws and browser policies, moving towards more privacy-preserving methods of user tracking and personalization.

The security of web cookies is mandatory in safeguarding user data and granting the integrity and confidentiality of web applications.

Let’s now delve deeper into strategies and mechanisms for enhancing cookie security, addressing advanced threats, and adhering to best practices in a sophisticated cybersecurity landscape.

Beyond merely setting cookies as secure, it's very important to enforce strict transport security headers, such as Strict-Transport-Security. This header ensures that browsers only communicate with the server over secure HTTPS connections, further reducing the risk of MitM attacks.

While marking cookies as HttpOnly protects them from direct access via client-side scripts, additional layers of security should be considered, and implementing Content Security Policy (CSP) directives can restrict the sources from which scripts can be loaded, further mitigating XSS risks.

For cookies that must store sensitive information, although generally discouraged, applying advanced encryption techniques is fundamental at this stage, and the advice here is to utilize strong encryption algorithms and key management practices to make sure that even if cookies are intercepted, the information remains secure and indecipherable.

The implementation of anti-CSRF tokens is a standard defense mechanism, but enhancing their security entails also making them both dynamic and encrypted. In fact, tokens should be unique per session or even per request, and their complexity should be increased through encryption, rendering them useless to potential attackers.

The SameSite attribute offers a powerful tool against CSRF, but its effectiveness depends on strategic application tailored to your application's needs:

• Strict Mode: For applications that do not require cross-site request functionality, setting cookies with SameSite=Strict provides the highest level of protection.
  
  

• Lax Mode: For most applications, SameSite=Lax offers a balance between security and usability, restricting cookie sending to only top-level GET requests.
  
  

• None Mode: When cross-site requests are essential, SameSite=None must be used in conjunction with the Secure attribute to ensure cookies are only sent over secure connections.

To protect against XSS, a well-defined CSP is essential. CSP should not only restrict the sources of scripts and resources but also be configured to report violations, to monitor and react to attempted attacks.

To prevent XSS attacks, rigorous input sanitization and validation are starting steps. All user inputs should be treated as untrusted, undergoing thorough validation against a strict whitelist of allowed content. Sanitization libraries and frameworks can provide an additional layer of security, so dangerous content is neutralized.

Correctly setting the Domain and Path attributes grants cookies that are only sent where intended, and in complex applications, segmenting them by their purpose and scoping them to the most restrictive domain and path can drastically minimize the risk of unauthorized access.

 For applications that handle varying levels of sensitive information, segmenting cookies based on their security requirements can enhance protection. For instance, separating session management cookies from tracking cookies allows for more stringent security measures to be applied where necessary.

Client-side vulnerabilities and web page protection in JavaScript go hand-in-hand when the concern is client-side security. JavaScript security threats and risks are a real concern. Moreover, JavaScript may represent a security vulnerability for businesses when the source code is provided by third-party providers, for example.

• First-Party JavaScript – The code an organization generates may have been secure when written. However, the code may have been tampered with after it went into production or reverse-engineered by malicious actors.

• Third-Party JavaScript – JavaScript code originating from third-party sources poses a significant risk because it has all the same privileges as first-party JavaScript code. Since there are no default security settings for third-party JavaScript, the organization that operates the website or app pulling in that code is responsible for enforcing security and continuous monitoring.

• Use of Forms and Secure Form Data – More than 90% of websites use forms to collect users’ personal information. Therefore, businesses must be committed to preventing breaches. On average, the personal information collected has a high level of exposure, involving more than 15 third-party domains, which increases the risk of unauthorized access to data and script misbehaviors.

  
  

Why do businesses need client-side security?

Client-side attacks have increased in cost and scale as companies expand their investments in the end-user digital experience. From Jscramblers’ experience, we give three fundamentals to start improvising the client-side security of your applications:

• Identify all third-party JavaScripts running on your web applications and website;

• Understand what these third-party JavaScripts are doing and why;

• Define which scripts are allowed to access data in forms on payment pages and block those that should not.

Web applications typically load 20 or more third-party scripts as part of the digital user experience. By not developing a client-side security strategy and approach, security teams allow third-party code libraries to run amok on their servers.

The relevance of third-party scripts for users’ digital experience creates a JavaScript supply chain, and the lack of client-side security measures generates potential vulnerabilities to a software supply chain implemented almost in real-time on users’ devices. That said:

• For businesses that accept online payments, users’ browsers may be facing a silent war.

• Website forms are open windows for data breaches.

• It is urgent to control third-party script behaviors on the client side, including tracking pixels and chatbots.

CSP exists as a security mechanism for web applications that helps detect and mitigate certain types of attacks, such as XSS attacks. This type of attack exploits the browser’s trust in the content received from a server.

A victim of an XSS attack is exposed to the execution of malicious scripts. Implementing CSP allows the owner/administrator of the website to reduce or eliminate the probability of an attacker triggering an XSS attack. It will specify which domains are safe and legitimate.

If a browser is CSP compliant, it’ll only run scripts from source files that are retrieved from whitelisted domains, ignoring all others. Additionally, a browser can also be told to only load certain protocols specified in the server.  For example, the server can determine that browsers can load content via HTTPS.

Essentially CSP allows the admin to be explicit about what resources should be trusted. Resources mean scripts, but also things like:

• stylesheets;

• media (for example audio and video);

• fonts;

• form actions;

• frame sources;

• types of objects and plugins.
  

In essence, what CSP provides is a means to “allowlist” the source of these resources. CSP is an important tool and should be used for any web application that manages sensitive data.

There are two ways to implement CSP:

• Via HTTP headers;

• Via meta tags in the HTML of the page.

HTTP headers are the recommended approach, and they can be set on the web server or set as required. Adding the CSP HTTP header to a web page and giving it values controls what resources the user agent is allowed to load for that page. There are plenty of CSP packages available in any programming language.

The following code is an example of setting up a CSP header using a package for Javascript.

var express = require('express');

var app = express();

var csp = require("simple-csp");

var csp_headers = {

    "default-src": ["'self'", "http://example.com"],

    "connect-src": ["'self'", "http://example.com"],

    "img-src": ["'self'", "data:", "http://example.com"]

};

app.use("/", function(req, res, done) {

    csp.header(csp_headers, res);

    done();

});

// Static files from ./public

app.use("/", express.static("./public"));

app.listen(8888);

It’s possible to specify what is to be trusted in different ways. These are just a few examples:

• Trust only scripts from the same source via HTTPS,

• Only allow images from a particular CDN

• Disallow frames

• Only allow fonts from Google Fonts

It’s important to note that CSP takes all inline scripts to be harmful.

Content Security Policy presents some advantageous key features, mainly about preventing code injection, clickjacking, and other client-side vulnerabilities.

Reporting is also a common tool to be used as a way to monitor potential vulnerabilities and report violations of the policy.

Granular control over resource loading: CSP offers fine-grained control over which content sources are allowed, allowing developers to specify different policies for different parts of a website or web application.

On the other hand, CSP is easy to misuse, and syntax mistakes are common since it is a manual tool. Some browsers work with it better than others, resulting in the applications still being vulnerable to attacks. Regarding Management Complexity, managing CSP may require a thorough understanding of the application's behavior and resource requirements. Incorrect configurations can break a website's functionality.

CSP also has some reduced flexibility – CSP can block a script from being loaded but is limited in the ability to block only specific behaviors of the script, for example, accessing data present on the page. Lastly, although modern web browsers support CSP, older browsers may not fully support all directives. Additionally, some older versions of browsers may exhibit inconsistent behavior with certain directives.

When it comes to PCI DSS v4 compliance, the CSP is mentioned by the PCI Security Standards Council as suitable to meet the requirements 6.4.3 and 11.6.1. It is mentioned together with SRI. SRI is a security feature that allows browsers to ensure that loaded resources (such as those from a third-party domain) have not been tampered with. It achieves this by enabling you to specify a cryptographic hash that the resource must match. The downside is that it is impossible to meet all the demands of the two requirements with just CSP and/or SRI.

The additional work is necessary to meet the requirements and can result in significant operational efforts. These efforts include dealing with unmanageable report volumes(with dynamically changing third-party hosted scripts), manual documentation for authorized scripts, constant hash maintenance to avoid functionality breaks, etc. Moreover, scripts have to be verified for the potential presence of skimming code, which CSP or SRI on their own do not provide. Finally, monitoring HTTP headers necessitates separate systems.