New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

What Happens When a Blog Engine Tries to Put on Big-Boy Pants

The Devil Is In The Details - WordPress

For me and my team at nvisionative we have never been tied to any one CMS. I have always said, our business does not rely on DNN. I realize this may come as a surprise to some of you in the DNN community, but it’s true. Rather than forcing everyone into one toolset, we focus on building solid solutions for our clients. To do that, we keep an open mind and use the right tool for the job. That said, when it makes sense, we do in fact choose DNN. However, there are times when we don’t have a choice in the matter and we are forced to use tools that are mandated by our client or are inherited from an existing client implementation. Lo and behold, sometimes (more times than we’d like to admit) those tools include WordPress.

The History

For those that do not know, WordPress was built initially as a personal publishing system (blog) and was actually built on top of, and as an official successor to, b2/cafelog. Its technical stack of choice was PHP and MySQL, sporting a General Public License (GPL), which made it quite attractive to the masses. It has gained tremendous popularity over the years and has grown into more of a Content Management System (CMS), though that is still debated by many whether or not it deserves a “CMS” designation. Nonetheless, according to W3Techs, WordPress powers 60% of all websites where they know the CMS and 30.9% of all websites.

The Choice

If you talk to nearly anyone in the WordPress Camp, they will tell you, “it’s easy, it’s free, and there is a plug-in for anything you want to do! So why not use it?”

The Concern

What they won’t tell you is what, perhaps, they don’t know. Herein lies the scary part and exactly why we are VERY CAREFUL when dealing with WordPress implementations.

The intent of this blog is not to be an extensive list of all things to be careful about (because that list is quite extensive). However, we realize many of you in the DNN community may have heard of, or even used, the whole security argument when evaluating DNN versus WordPress. Are we just to accept the argument though and leave it to generalizations when making a case to clients or ourselves? Trust it blindly? I believe not! Therefore, I will expose just one security vulnerability that alone should be enough to help you make an educated decision.

The Details

In recent versions of WordPress, there is a REST API. On the surface, this a really great thing! It allows you to improve the overall user experience by building fast client-side features via plugins that can make API calls for access to server-side data without having to rely on slower PHP hooks for that server-side data access.

You can also use the REST API to integrate third-party apps (e.g., other web apps, mobile apps) to access data such as posts, categories, tags, media and much more. Some API actions require authentication. For example, creating, updating or deleting a post. Cookie authentication is the only authentication mechanism available natively in WordPress, but there are plugins that may be added to provide other authentication methods such as OAuth and JSON Web Tokens (JWT). An authentication plugin is required for authenticated requests from outside of the WordPress admin, themes, or plugins.

Most of the GET (read-only) requests though are possible anonymously. This makes accessing most data extremely easy. So, if you just want to see the data, you don’t even have to write a single line of code!

The WordPress REST API uses a format like the following for their endpoints (URL methods that perform a specific function):<object_method>

These endpoints are intended for use within the context of code. However, to see the response information for an endpoint without writing a single line of code, you can access the URL in any modern web browser and in return view a JSON response. So, ready for the really scary part?

The Scary Details

First, let me say, not all WordPress sites will apply. It depends on the specific version of WordPress and whether or not any measures have been taken to address this vulnerability, either by custom code, plug-in or built-in hosting provider mechanisms. That said, an out-of-box implementation of WordPress 4.7 will expose a list of all USERS via anonymous access, including each user’s name, username, Gravatar link and other associated meta data! Following is an example from a prominent tech news site. For security reasons I have obfuscated any sensitive data.

Sample User

This information can be exposed to and enumerated by both humans and BOTs to harvest sensitive information. With this information in hand, brute-force attacks can be made against the website to gain unauthorized access. And people wonder why so many WordPress sites get hacked?

The Response

What does the WordPress REST API Team have to say about this? Well, hold on to your butts…here it goes…

"Usernames are already exposed through themes, RSS feeds, etc, and we do not consider them a security issue. You can install a third-party plugin if you would like to limit access to this data."


The Alternative

We all know DNN (DotNetNuke) has not been unscathed over the years from security vulnerabilities. However, being in the community since Day 1, I can still count the number of substantial security vulnerabilities on just one hand. That is saying something! And even during those times, the vulnerabilities were addressed in a timely and sensitive manner, and, weren’t as serious and as blatantly obvious as this WordPress vulnerability (which is STILL in their documentation as of the date of the writing of this blog).

If this level of security vulnerability (as a feature nonetheless) can be released like this, you must put into question EVERY update over time and especially in the future. Now that stronger regulations are being imposed, like GDPR, your business as a whole is more vulnerable than ever. I know some CMS consultants that go as far to tell clients they won't even touch WordPress sites due to the level of risk it puts on their own companies.

The Saving Grace

For a moment, let's assume you have one or more WordPress sites, are reading this blog, and are now concerned about what to do. You have invested a great deal into making your WordPress site great, but now you are worried about it being vulnerable. The bad news is you probably should be worried. The good news is we can help you either get onto a more secure CMS (like DNN) or, worst case scenario, help secure your WordPress site(s).

The Bottom Line

I hope having a concrete example helps you make solid decisions for yourself, your company, and your clients. Out with liability-first and in with security-first!



Will Strohl
It's insane that they don't recognize the existence and gravity of the security issue you're highlighting.
Will Strohl Monday, June 11, 2018 3:47 AM (link)
David Poindexter
I agree whole-hardheartedly Will. I was honestly shocked in this discovery!
David Poindexter Monday, June 11, 2018 5:35 PM (link)
Will Strohl
Just because sensitive data can be achieved via other means, doesn't mean that you should just continue to expose it. Close the hole, in all places. Reach out to any vendors that are exposing this data. Let everyone know that this exists and how to prevent it. It's so simple...
Will Strohl Monday, June 11, 2018 6:30 PM (link)
Ryan Moore
I'm so glad you wrote this up as an article/case study David!

To the point of "counting major vulnerabilities in one hand" I'll weigh in too by saying that two of those were not even DNN-specific, they were .Net or component/tool related and they affected all types of ASP.NET sites. The fact that DNN has been built from the ground up as security and stability focused has always been a major point in our discussions with clients.

By the way, if you're reading this and would like to join in on conversations like this one, David was talking about this after our last Southern Fried DNN User Group meeting... It was the main topic around food and drinks that night. If you're able to join us for meetings (Third Thursday of every month) then you're sure to catch these types of conversations and ideas on the regular as we all discuss the issues we encounter every day as developers and service providers.

Thanks again David for an excellent post!

Southern Fried DNN User Group
Ryan Moore Monday, June 11, 2018 7:17 PM (link)
Will Strohl
Great point about the security issues, Ryan. :)
Will Strohl Monday, June 11, 2018 8:34 PM (link)
Winston Haybittle
Great post - Yes I've had the "security argument" conversation too many times to count and reassuring clients of DNN's security awareness and dedication to security has definitely saved the day a number of times.
Winston Haybittle Sunday, July 29, 2018 5:28 PM (link)
David Poindexter
Thanks everyone. I had a feeling we were not along in our thoughts on this matter! :)
David Poindexter Monday, July 30, 2018 7:35 PM (link)

Comment Form

Only registered users may post comments.


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Davies (3)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (37)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (213)
Chris Paterra (55)
Clint Patterson (108)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (181)
Daniel Valadas (48)
Dave Buckner (2)
David Poindexter (12)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (80)
Francisco Perez Andres (17)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (4)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (2)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (40)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Patricio F. Salinas (1)
Patrick Ryan (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott Schlesier (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Tony Henrich (3)
Torsten Weggen (3)
Tycho de Waard (4)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (180)
William Severance (5)
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out