Security researchers at Feroot are warning application security professionals of the client-side security risk associated with unprotected cookie structures. Because cookies are so ubiquitous with all website types—from e-commerce and banking to social networks and SaaS applications—organizations need to be aware of the privacy and data exploitation risks associated with poor cookie security.
Can you name the top cybersecurity risks for banking and investment? Most would probably list cyber attacks like phishing, credential theft, DDoS, and maybe ransomware. But would it surprise you to learn that there is something on the list that many in the banking and investment industry forget–and that’s client-side cybersecurity threats. You know the kind…the ones related to jQuery, cross-site scripting (XSS), JavaScript injections, formjacking, etc.
A few weeks ago we wrote about the “creepy, problematic, and potentially illegal” problems associated with web tracker security—in particular, the security risks of Facebook’s Meta Pixel, its ability to collect and use sensitive healthcare data, and the risks of hospital privacy lawsuits.
When it comes to client-side security, creating and deploying a content security policy (CSP) can serve as a solid starting point. To deploy a content security policy, you must first identify assets, including first- and third-party resources that will be loaded in the browser when a user visits your website. For those who haven’t heard of a content security policy (CSP), you probably know that it’s easier said than done. Let’s talk about what those steps are to deploy a CSP.
When it comes to security and healthcare, most patients expect, at the very least, doctor-patient confidentiality. If web trackers are embedded within the JavaScript on a healthcare website you expect full security. I mean, you shouldn’t have to worry about someone working at Facebook knowing your personal healthcare information, like the details of a doctor’s appointment, right?
I am a credit card skimming attack victim. It happened about eight weeks ago, and to this day, we’re still dealing with the repercussions. This is a true story. (Although I did substitute a few facts to protect the innocent.) And yes, while I work for Feroot, and this is appearing in our blog, I think it is important that cybersecurity professionals hear first hand from a card skimming attack victim—someone who is like every other customer that their business supports.
Generating a generic content security policy is easy. Manually managing those policies to ensure they operate effectively and provide the right level of security is an entirely different issue. For businesses willing to make the shift, an automated content security policy can significantly ease the policy management burden.
When client-side security breaches happen, web application developers may find themselves at the receiving end of the blame game (somewhat unfairly). The demands of an accelerated development cycle combined with pressures related to JavaScript web applications security, means developers may feel caught in the proverbial “damned if you do and damned if you don’t” loop.
PCI DSS 4.0 couldn’t have come at a more opportune time, particularly as the global pandemic forces more individuals into online purchasing—from shopping and entertainment to healthcare and hospitality. With PCI 4.0 compliance mandated by 2025, it is critical to understand now what it will mean for client-side security, so businesses can begin the implementation process.
Web application visibility is all about the insight and control application security professionals have into the software operating on the front end or client side. Sitting down to write about why web application visibility is important to JavaScript security, I was reminded of a folk song about coding that was popular back in the 1980s. (Yes, you read that right. A popular folk song about coding. Fans of Stan Rogers or listeners of the cult-favorite, syndicated radio show known as Dr.
