security

Last week, we listed 16 practices to help secure one’s APIs and described how to implement them with Apache APISIX. Authentication 🕵️️ - Verifies the identity of users accessing APIs.Authorization 🚦 - Determines permissions of authenticated users.Data Redaction 🖍️ - Obscures sensitive data for protection.Encryption 🔒 - Encodes data so only authorized parties can decode it.Error Handling ❌ - Manages responses when things go wrong, avoiding revealing sensitive info.

A couple of months ago, I stumbled upon this list of Secure your API with these 16 practices to secure your API: Authentication 🕵️️ - Verifies the identity of users accessing APIs.Authorization 🚦 - Determines permissions of authenticated users.Data Redaction 🖍️ - Obscures sensitive data for protection.Encryption 🔒 - Encodes data so only authorized parties can decode it.Error Handling ❌ - Manages responses when things go wrong, avoiding revealing sensitive info.

A couple of months ago, I stumbled upon this list of 16 practices to secure your API: Authentication 🕵️️ - Verifies the identity of users accessing APIs.Authorization 🚦 - Determines permissions of authenticated users.Data Redaction 🖍️ - Obscures sensitive data for protection.Encryption 🔒 - Encodes data so only authorized parties can decode it.Error Handling ❌ - Manages responses when things go wrong, avoiding revealing sensitive info.

I never moved away from Docker Desktop. For some time, after you use it to build an image, it prints a message: What's Next? View a summary of image vulnerabilities and recommendations → docker scout quickview I decided to give it a try. I’ll use the root commit of my OpenTelemetry tracing demo. Let’s execute the proposed command: docker scout quickview otel-catalog:1.

Security in one’s information system has always been among the most critical Non-Functional Requirements. Transport Secure Layer, aka TLS, formerly SSL, is among its many pillars. In this post, I’ll show how to configure TLS for the Apache APISIX API Gateway. TLS in a few words TLS offers several capabilities: Server authentication: the client is confident that the server it exchanges data with is the right one.

API Gateways are critical components in one’s infrastructure. If an attacker could change the configuration of routes, they could direct traffic to their infrastructure. Consequences could range from data theft to financial losses. Worse, data theft could only be noticed after a long time by mirroring the load. Hence, protecting your API Gateway is of utmost importance. In this short blog post, I’ll list a couple of ways to secure your Apache APISIX admin access.

API management solutions, also known as API gateways, are a must in the day and age of APIs. However, once you’ve set up such a gateway, you can use it for different purposes unrelated to APIs. Today, I want to show you how to improve the security of web apps. Prevent sniffing Browsers are fantastic pieces of technology that try to make the life of users as comfortable as possible.

Last year, I spoke at the National DevOps Conference that took place at the British Museum. I had already visited the museum before, but speaking there was a fantastic experience. Besides, we had the museum all for ourselves for a couple of hours. If you’ve ever visited the place, you know what I mean. Anyway, I also attended a talk about Checkov: Checkov scans cloud infrastructure configurations to find misconfigurations before they’re deployed.

Security is the poster child of a Non-Functional Requirement: most people don’t care until the proverbial fecal matter hits the rotary propeller. Consequences can range from losing reputation to legal liability to putting the business out. In my post on running unsecured code, I concluded that you should treat security as a risk - and left it at that. I think it warrants a dedicated post. Risk management is pretty much documented.

Last December, Log4Shell shortened the nights of many people in the JVM world. Worse, using the earthquake analogy caused many aftershocks after the initial quake. I immediately made the connection between Log4Shell and the Security Manager. At first, I didn’t want to write about it, but I’ve received requests to do so, and I couldn’t walk away. Hey @nicolas_frankel, isn't the #Log4j-Exploit the perfect argument against deprecation of the Java SecurityManager?!

A couple of years ago, I attended a talk of my former colleague (but still friend) Volker Simonis. It gave me the idea to dig a bit into the subject of how to secure the JVM. From the material, I created a series of blog posts as well as a talk. From that point on, I submitted the talk at meetups and conferences, where it was well-received. Because I like to explore different areas, I stopped to submit other proposals. Still, the talk is in my portfolio, and it was requested again in 2021.

This is the 5th post in the JVM Security focus series. A post brought to light an interesting feature of the JDK I didn’t know about: the ability to update a code running in a JVM. The referenced post shows how to apply a bugfix using that feature. The devious white hat JVM hacker in me started to think how one could apply that trick for other less beneficial purposes. And of course, how to prevent that.

This is the 4th post in the JVM Security focus series. In one of my previous posts, I described how to create a custom policy file for one’s application. The process was manual and incremental. Because of that, it was painstakingly long, and hence not really useful. Since I wrote the post, I found a way to write the policy file under in a couple of hours, instead of days.

If you already had to manage some degree of randomness on Java, chances are you got acquainted with the Math.random() methods. However, the previous method returns a double. Beyond very basic use-cases, another option has to be considered, in the form of the java.util.Random class. Random An instance of this class is used to generate a stream of pseudorandom numbers. — JavaDoc https://docs.oracle.com/javase/8/docs/api/java/util/Random.

This is the 3rd post in the JVM Security focus series. Last week, I wrote about the JVM policy file that explicitly lists allowed sensitive API calls when running the JVM in sandboxed mode. This week, I’d like to improve the security by signing the JAR.

This is the 2nd post in the JVM Security focus series. I’ve already written about the JVM security manager, and why it should be used - despite it being rarely the case, if ever. However, just advocating for it won’t change the harsh reality unless some guidelines are provided to do so. This post has the ambition to be the basis of such guidelines. As a reminder, the JVM can run in two different modes, standard and sandboxed.

Java makes it possible to compile Java code at runtime…​ any Java code. The entry-point to the compilation is the ToolProvider class. From its Javadoc: Provides methods for locating tool providers, for example, providers of compilers. This class complements the functionality of ServiceLoader. This class is available in Java since version 1.6 - released 10 years ago, but seems to have been largely ignored.

My next book review will be on Spring Security 3 from Packt.