As a person who has had to deal with plagiarism of my own articles, I found the similarities between the first part of this article and the guidelines given by the authors of the book Securing Java in chapter 7 section 1 to be eerily close. Fortunately, this book is freely available on the net and I will leave you to make a decisive judgement on whether the first part of this article is plagiarized to a heavy degree or not. (Note that the authors give a link to the book in the list of references. However, that does not allow them to plagiarize its contents.)
The original book contents:http://www.securingjava.com/chapter-seven/chapter-seven-1.html
All rules, except for rule 6, have been lifted straight out of this book. Further, the article authors have gone ahead and lifted the text describing the rules as well out of this book. Listed below are only some of the sample areas where the plagiarism is seriously obvious.
1. Consider part of rule 3 in the offending article:
"Java's object cloning mechanism can allow an attacker to manufacture new instances of classes that you define, without executing any of the class's constructors. Even if your class is not cloneable, the attacker can define a subclass of your class, make the subclass implement java.lang.Cloneable, then create new instances of your class by copying the memory images of existing objects. By defining the above clone method, you'll prevent such attacks."
and the same rule description in the original book (rule 8)
"Java's object-cloning mechanism can allow an attacker to manufacture new instances of classes you define, without executing any of your constructors. If your class is not cloneable, the attacker can define a subclass of your class, and make the subclass implement java.lang.Cloneable. This allows the attacker to make new instances of your class. The new instances are made by copying the memory images of existing objects; although this is sometimes an acceptable way to make a new object, it often is not."
2. Consider rule 7 in the offending article:
"If a class, method, or variable is not private, hackers could use it as a potential entry point. If there is a good reason why a method, field, or class should not be private, it does not need to be private, but that reason should be clearly documented."
and the same rule in the online version of the book (rule 2):
"Every class, method, and variable that is not private provides a potential entry point for an attacker. By default, everything should be private. Make something non-private only if there is a good reason, and document that reason."
3. Finally, consider rule 4 in the offending article:
This rule requires that if you want to prevent access to the internal state of your objects, make your class nonserializable. If you don't, your objects can be serialized into readable byte arrays. As a result, hackers can view the objects' full internal state, including private fields and the internal states of referenced objects.
And the same in the book:
Serialization is dangerous because it allows adversaries to get their hands on the internal state of your objects. An adversary can serialize one of your objects into a byte array that can be read. This allows the adversary to inspect the full internal state of your object, including any fields you marked private as well as the internal state of any objects you reference.
I will leave you to compare the rest of the article and the book's contents.