Wordfence is now a CVE Numbering Authority (CNA)

Today, we are excited to announce that Wordfence is authorized by the Common Vulnerabilities and Exposures (CVE®) Program as a CNA, or CVE Numbering Authority. As a CNA, Wordfence can now assign CVE IDs for new vulnerabilities in WordPress Core, WordPress Plugins and WordPress Themes.

WordPress powers over 40% of the World Wide Web in 2021. By becoming a CNA, Wordfence expands our ability to elevate and accelerate WordPress security research. This furthers our goal of helping to protect the community of WordPress site owners and developers, and the millions of website users that access WordPress every day.

What is a CNA?

The acronym CNA stands for CVE Numbering Authority. A CNA is an organization that has the authority to assign CVE IDs to vulnerabilities for a defined scope. As a CNA, Wordfence can assign CVE IDs to WordPress Plugins, Themes, and Core Vulnerabilities.

What is a CVE?

CVE is an international, community-based effort and relies on the community to discover vulnerabilities. The vulnerabilities are discovered then assigned and published to the CVE List. The mission of the Common Vulnerabilities and Exposures (CVE®) Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. There is one CVE Record for each vulnerability in the catalog.

What does this mean for Wordfence customers?

As the Wordfence Threat Intelligence team continues to produce groundbreaking WordPress security research, Wordfence can more efficiently assign CVE IDs prior to publicly disclosing any vulnerabilities that our team discovers. This means that a CVE ID will be immediately assigned with every vulnerability we discover rather than waiting for an assignment from an external CNA.

To report a vulnerability, even if there is uncertainty about the responsible disclosure process, proof of concept production, or mitigation review procedures, the Wordfence Threat Intelligence team is available to assist. Our highly credentialed team has expertise and experience in proper security disclosure and can assist in ensuring that adequate remediation of vulnerabilities, no matter the severity, are applied and verified. As the original researcher, you receive the CVE ID and public credit for your discovery. You will also receive thanks from the users and community that you have protected through your responsible disclosure. Please reach out to us and we will be happy to assist.

How to report vulnerabilities to Wordfence for CVE assignment and publication?

To report a vulnerability to Wordfence for a WordPress plugin, WordPress theme, or WordPress core, please reach out to security@wordfence.com with the vulnerability information. Please include the following details:

  • A concise description of the vulnerability.
  • A proof of concept – that is, how the vulnerability could potentially be exploited.
  • What software component in our scope is affected – namely, which plugin or theme is affected, or which part of WordPress core.
  • The version number(s) affected.
  • The name(s) of individuals you would like credited for the discovery – or indicate if you would like to remain anonymous.
  • Any other additional information as appropriate.

The Wordfence Threat Intelligence team will review your findings and report back within 1-3 business days with a CVE ID assignment, or a request for additional information.

Community engagement and outreach at Wordfence has helped accelerate our efforts to secure the global WordPress community. Becoming a CNA has helped further this goal. Our team looks forward to expediting our own research and helping to encourage and enable new researchers to join the growing community of people who discover and responsibly disclose WordPress vulnerabilities. Together we can work towards a safer Web for all.

Source :

What is a WordPress Firewall and Do You Need One

The word firewall gives the impression that once installed on your WordPress site nothing will be able to attack it and you don’t need any other security measures applied. This is not true.

A firewall can only act on the WordPress site code level, it can not ever affect lower levels on your server such as blocking IP addresses and ports to your server. 

There is no WordPress plugin that can do that. 

So Why Then Have a WordPress Firewall At All?

Let’s break it down for you.

The WordPress firewall detects and blocks responses from malicious data.

What does that mean?

When data is transferred on your site, such as a user logging in or a blog post or image being displayed, the firewall hides this data from prying, malicious, eyes.

It applies a set of rules for incoming and outgoing traffic in order to protect your website.

It’s similar to an SSL, but an SSL only encrypts the data and then the firewall hides it.

A Firewall Has Several Methods To Protect Your Site

  • FIltering
    • This allows the filtering of traffic so that only legitimate users can access your site based upon rules that you set
  • Proxy
    • A proxy is like a security guard. It is the middleman that stops bad traffic from getting to your site
  • Inspection
    • A firewall allows you to set variables for trusted information. It then inspects all data coming in and if the key elements are not found agreeable in comparison to your set variables it doesn’t allow it through.

These methods are an important part of keeping your site secure. It helps drastically reduce the amount of attacks and malicious code injections that your security service/plugin needs to handle. 

What Are The Recommend Settings For Your Firewall

Most firewall and security plugins have a set standard for recommended settings, but there are a few items that are crucial to the success of its application:

  • Firewall Block Response
    • Specify how the security plugin will respond when the firewall detects malicious data.
  • Firewall White Listing and Ignore Options
    • Specify certain factors that completely bypass all Firewall checking.
    • These options should be used sparingly and with caution since you never want to white list anyone, even yourself, unless you really must.
  • Firewall Blocking Options
    • There are 9 firewall options that determine what data is checked on each page request. Depending on certain incompatibilities with other plugins, you may need to disable certain options to ensure maximum compatibility.
    • These firewall options are:
      • Include cookies
      • Directory traversal
      • WordPres terms
      • Field truncation
      • PHP code
      • Exe file uploads
      • Lead schemas

This might all seem overwhelming, but luckily for you our ShieldFREE and ShieldPRO have all of the above and more inside its robust feature list. It’s fully customizable and easy to use.

Keeping your site up and running is crucial for any business and having a reliable firewall plays a major part in that.

If you have any questions about the firewall or wish to request some features, please drop us a message in the comments section below, or contact us in our support center.

Source :

WordPress Security Guide: 14 Actionable Tips to Harden WordPress

If you have a website running on WordPress then ensuring its security should be your foremost concern. But before you even begin to harden WordPress, you should first know…

Why WordPress Security is Important?

  1. WordPress accounted for 90% of all hacked sites that were fixed by Sucuri in 2018 as per this report.
  2. WordPress sets the default username to Admin which is child’s play to guess for anyone.
  3. WordPress reveals the username in the author slug by default.
  4. An intruder can access your site’s database tables which are, by default, set to wp_prefix and can be guessed easily, unless modified.
  5. Your site is vulnerable to DoS (denial of service) attacks which can result in prolonged downtime.
  6. A hacker can inject malicious code in your website’s database without your knowledge.
  7. And many more reasons as revealed by this WordPress security infographic.

This WordPress Security guide provides only the most useful tips for securing and hardening your WordPress site that you can implement right away, leaving you with ample time to focus on other important aspects of your website.

So let’s start.WordPress Security Checklist

1. Keep a Strong Password that is Hard to Crack

When you install WordPress on your site for the first time, you have to fill in the password among other details. An easy to crack password is the simplest way a hacker can gain access to your website. So what’s the solution?

Make sure you set a strong password containing a combination of uppercase and lowercase alphabets, characters and numbers that cannot be guessed. Please don’t keep a hacker-friendly password like “your name” or “password”.

The second tip is that you should never disclose your site password to anyone. If you have to provide your login details for support purposes to some 3rd party, make sure to change your password once the support issue is resolved.

2. Keep a Username that Cannot be Guessed

By default, WordPress sets the username to ‘admin’ at the time of installation. Nothing could be easier to guess than this. So please make sure to set a hard-to-guess username when you install WordPress.

But this is just the first step.

The second step is to hide your username from the site visitors since WordPress reveals your username in the author profile.

So head over to Admin menu>Users>Your Profile and change your Nickname from your admin username to something different, most probably your real name, and then select your newly created Nickname from the ‘Display name publicly as‘ dropdown.

3. Change the Author Slug to Hide Your Username

But even after you change the author nickname, WordPress reveals your real username in the author ‘slug’ or URL whenever anyone hovers over the author name. So, you should hide your real username in the author ‘slug’.

But how do you hide your username in the author slug or URL? There are two easy ways to do this.

The first method is by using a free plugin like Edit Author Slug.

Or if you’re like me and would rather do it manually rather than installing a plugin, then the second method is the best solution and hardly takes 5 minutes to implement.

Head over to phpMyadmin in your cPanel (hopefully your web host allows access to the php database). Once inside phpMyAdmin panel, from the left menu of scroll to the wp_users table (replace ‘wp’ with your database tables prefix).

You will see your login details here. You should change the user_nicename from your actual username to something different and then save the changes. That’s it; your real username will no longer be displayed on your author slug.

4. Setup 2-Factor Authentication for Login

Want to ensure fool-proof login security? Then consider setting up 2-factor authentication (2FA) for your login page. This way no intruder can gain access to your site even he manages to crack your password.

Now, you should know that different types of 2FA are available like SMS based or app-based. For the purpose of this step, we will use an app-based 2FA for securing the WordPress login page.

First, install the Google Authenticator plugin on your site. Of course, you must have the Google Authenticator app installed on your phone. If you have not already installed it, do it before proceeding to the next step.

Now in the settings page of the plugin, click on the Configure button under the Google Authenticator tab. It will ask you to first create a mini orange account (the plugin creator) which will take about 10 seconds. Now onto the next step.

Then scan the bar code using the Google Authenticator app on your mobile. Notice that you can also use the LastPass authenticator here if you prefer this app.

Finally, just enter the one time code and you are all set. But don’t forget to tick the “Enable 2FA prompt on the WP Login Page” checkbox.

Now when you log in to your site the next time, you will see an additional 2FA prompt below the email and password boxes like this.

5. Secure your .htaccess File for First Line of Defence

The .htaccess file is an Apache Web Server file that enables basic redirects and is also useful for enhancing your website security.

It is a good first line of defence for securing your website.

Your .htaccess file can secure your website in the following ways by:

  1. Restricting access to important files and folders
  2. Disabling directory browsing
  3. Allowing only specific IPs to access the Admin area
  4. Disabling access to XML-RPC File
  5. Blocking author scans

Now let’s start adding the code snippets for each of the above steps. Remember, you need to add the snippets listed in the following steps in your .htaccess file outside the #Begin WordPress and #End WordPress tags.

1. Restrict access to important files and folders

You should restrict access to important files such as wp-config.php, php.ini and .htaccess itself since no one but yourself should have a concern with these files. Just add the following snippet to restrict access.

# Block wp-config, php.ini and .htaccess
<FilesMatch "^.*(error_log|wp-config\.php|php.ini|\.[hH][tT][aApP].*)$">
Order deny,allow
Deny from all

Next, you should disable access to the wp-includes folder since this folder contains files that are required to run the WordPress core minus the plugins and themes. So why should anyone snoop around in this folder?

# Block wp-includes folder and files
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]

2. Disable directory browsing

What’s easier to break into for a thief, a home whose plan details are known or one whose are unknown? Similarly, if your site’s file and directory structure is visible, it will be easier for hackers to break into your site.

To prevent this, you should disable directory browsing by adding the following code.

Options -Indexes

3. Allow only specific IPs to access the Admin area

If you’re running a single author blog and access your site from known IPs, then you can only allow these known IPs to access the WordPress admin area by inserting the following snippet.

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "WordPress Admin Access Control"
AuthType Basic
order deny,allow
deny from all
# whitelist Syed's IP address
allow from xx.xx.xx.xxx
# whitelist David's IP address
allow from xx.xx.xx.xxx

Remember to replace the xx in the snippet above with your IP. If you access your site from multiple IPs, then insert all the IPs in the ‘all from’ line.

4. Disable access to XML-RPC File

The XML-RPC file enables 3rd party application access to your website. If you’re not giving access to any 3rd party app, it’s advisable to disable access to the XML-RPC file since it could be used by hackers gain backdoor entry to your site.

Just add the following code in the .htaccess file to do this.

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all

5. Block author scans

Another way hackers can gain entry to your WordPress site is by scanning all the usernames used on your site and then trying to crack your admin password with those usernames. This is typical of a brute force attack.

To prevent anyone from fishing for usernames, you should block author scans by adding the following snippet in the .htaccess file.

# BEGIN block author scans
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} (author=\d+) [NC]
RewriteRule .* - [F]
# END block author scans 

6. Use a Security Plugin for All-round Protection

A good security plugin is essential to enhance your WordPress site’s security. There are many plugins available to boost your site’s security but some of the better ones include All-In-One WP Security & Firewall (which I use and recommend), BulletProof Security and iThemes Security.

Why I Recommend the All-in-One WP Security and Firewall plugin?

The free All-In-One WP Security & Firewall plugin has very useful features, including:

  1. It checks whether you have changed the default ‘admin’ username or not. It also checks your password strength using a Password Strength Tool.
  2. It has many user login options, including, options for preventing rogue sign-ins and site lockout features.
  3. If you allow user registration, you can implement captcha on the registration and login pages.
  4. Checks whether you still use the default wp_ prefix for your database tables and provides the option to change the database prefix.
  5. Enables automated backups of your database.
  6. Has multiple file security options, including, setting the default file permissions, disabling PHP file editing within the dashboard etc.
  7. You can ban multiple users by IPs or user agents.
  8. Has advanced firewall rules to completely secure your WordPress site.
  9. Prevents brute force attacks by using advanced options.
  10. Prevents comment spam by deploying captcha on the comment form and blocking comment spambots.
  11. WordPress scanner to detect changes in files
  12. And many more features.

7. Protect Your Site from DDoS Attacks

If you’re running a popular WordPress website with high traffic, your site could be vulnerable to DDoS (Distributed Denial of Service) attacks that can result in unscheduled downtime and loss of revenue.

There are multiple ways to prevent such an attack from occurring. The first is at the server or hosting level. Your hosting company could offer a DoS attack protection. If you haven’t decided on your web host yet, you can consider WPX Hosting that offers comprehensive website security for free.

The second method is to use a free CDN like Cloudflare that offers free DoS mitigation plans at the entry-level which are good enough for sites with moderate traffic.

8. Make Regular Backups for Unforeseen Situations

In the event of any disruption on your site, you could lose all your hard work, including, your posts. To prevent such an extreme event from occurring it is always advisable to maintain regular backups of your WordPress site.

Again, there are two ways to do this.

The first method is to find a web host that offers free daily backups. If you’re using managed WordPress hosting, chances are your web host already offers free daily backups. Even if not, you can check out with your host regarding this must-have feature.

The second method is to use a free plugin like UpdraftPlus that allows you to schedule daily automatic backups directly to Dropbox, Google Drive, Amazon S3 etc.

9. Use SSL to Encrypt the Connection between Your Site and Users

Secure Socket Layer (SSL) encrypts the information between your web host server and the visitors’ browser preventing leaking of sensitive information like their payment credentials to curious eavesdroppers.

Apart from the security aspect, SSL is also a ranking factor in Google’s search results and you would do well to implement it on your site. That’s why I recommend implementing SSL on your website. You can also get free SSL from some web hosts. Read on to know more.

10. Use Secure Hosting to Fortify Your Site

You may have taken the utmost care to secure your WordPress site, but what if your web server is prone to malicious attacks? There isn’t much you can do in this case.

But what you can and should do is to choose a web host that provides the maximum security to your websites. What kind of security am I talking about?

Well, the most important security feature your web host can provide is free malware scanning. After all, malware removal can cost an arm and length once your site is hit by a malware.

Fortunately, help is at hand.

We use WPX hosting for hosting all our websites since they provide the following three crucial features for securing my website, absolutely free of cost:

  1. Free malware scanning and removal
  2. Free SSL certificate for all my sites
  3. Free daily backups

I also have to add that WPX Hosting provides free cloud-based CDN (content delivery network) and a managed WordPress hosting support experience that I absolutely love.

11. Change the Database Table Prefix to Deter Hackers

Your WordPress database is vulnerable to MySQL injection if a hacker can get his hands on it. You cannot completely secure your WordPress database but you sure can make it difficult for hackers to find your database tables by changing their default prefix from “wp_” to something difficult to guess.

The easiest way to change your database table prefix is by using the terrific (and free) security plugin All-in-One WP Security and Firewall.

12. Update Your Plugins and Themes to Prevent Backdoor Access

Plugins are arguably the primary reason to use WordPress over any other CMS. They extend WordPress capabilities in a limitless manner. But they are also a source of malicious code which could play havoc with your website.

To avoid this possibility, make sure you install only legitimate plugins on your site and avoid any hacked or nulled plugin like the plague since the person who nulled the plugin could also embed some unsuspecting malware into the plugin.

Also, make sure to install the latest version of the plugin since these usually contain many bug fixes. If the plugin hasn’t been updated in a long time, it may be wiser to switch to an alternative.

Speaking of the latest version, make sure to…

13. Enable Auto Updates for Plugins and Themes

If you use many plugins, there may be frequent updates and updating these plugins will in itself become a chore for you. One easy fix for this is to use the JetPack plugin by Automattic (the creators of WordPress).

Jetpack has this wonderful option to enable auto-updates for all plugins that you install from WordPress.org repository. Remember, you will still need to update any 3rd party plugin manually.

But I am assuming that the bulk of your plugins will be free plugins installed from WordPress.org and you can enable auto-updates for all of these.

The second method is even better since you can auto-update not just your plugins but also themes and even the major versions of WordPress. However, you should not use this if there is a possibility of the updates breaking your site.

Just insert the following code in the wp-config.php file, which is located in the public_html directory.

define('WP_AUTO_UPDATE_CORE', true);
 add_filter( 'auto_update_plugin', '__return_true' );
 add_filter( 'auto_update_theme', '__return_true' );

14. Disable the Theme and Plugin Editor

You should also consider disabling access to the theme and plugin editor within your WordPress admin dashboard as an added security measure to prevent users with admin access to tinker with your database.

Just add the following single line of code in the wp-config.php file.

define('DISALLOW_FILE_EDIT', true);

And there we have it. 14 in-depth tips to take your WordPress security to the next level and protect your site from most of the attacks that could be directed its way.

What do you feel about these tips to harden WordPress security and how many have you implemented on tour site? Let me know in the comments.

Please Note: This page contains affiliate links to products or services that are tried and tested by us. If you buy the product or service using our affiliate links, at no additional cost to you, it will help us to maintain this site and publish useful content regularly. Thank you.

Source :

How to Fix “the response is not a valid JSON response” Error in WordPress

You are creating content in the WordPress editor but the document fails to update. In fact, you see an error message that says “Updating failed. Error message: The response is not a valid JSON response.” Before you panic, let me assure you that this error can be resolved easily so you don’t lose your hard work.

Why does “the response is not a valid JSON response” error occur?

There could be multiple reasons why this error occurs. This post delves into each reason and offers multiple solutions to solve the problem.

Disable the Block editor and switch back to Classic editor

Old is still Gold in WordPress

The error “Updating failed. Error message: The response is not a valid JSON response.” is overwhelmingly seen in the new Block editor called Gutenberg.

The easiest way to resolve the updating error is by disabling Gutenberg and switching back to the Classic editor. As they say, old is Gold.

You can install the Classic Editor plugin for this. Once you have activated the plugin, try to save your posts. You should not see any error message now.

But what if you still want to use the block editor?

Nice question. It could be that reverting to the classic editor is not an option for you. In that case, you should follow what we are doing on PassionWP. With the classic editor plugin installed and activated, navigate to Settings>Writing.

Now select the Classic Editor as the “default editor for all users” option, save your changes, and clear your website cache. Right after this, select the Block Editor as the default editor and again save the changes.

Classic Editor plugin settings

Now try editing an existing post or create a new post with the block editor. You should not encounter the JSON response error. However, it could be that the editor fails to automatically save your changes.

In this event, press Ctrl + S (Cmd + S for Mac) to manually save your changes. This solution works for us and we are using the block editor without encountering the JSON response error.

Mixed content error due to the use of SSL certificate

Another common reason for this error is the use of a secure socket layer (SSL) certificate (Https) on your WordPress site. Using an SSL certificate can result in some content being delivered non-securely on Http protocol even while the rest of the content is delivered in a secure manner over Https protocol.

This results in a mixed content error in which both https and https content is transmitted at the same time to the web browser, usually Google Chrome.

How to solve the Mixed Content Error in WordPress?

We investigated the mixed content error and noticed that it is linked to the use of the Really Simple SSL plugin that is used by over 3 million WordPress users to configure https on their websites.

To resolve the “the response is not a valid JSON response” or mixed content error, navigate to Settings > SSL. This will open the plugin’s settings. Now click on the Settings tab.

You should do the following two things here:

  1. Ensure that the “Mixed content fixer” option is turned on. This prevents mixed content problems on your website that we discussed above.
  2. Next, you should turn on the “Use an alternative method to fix the mixed content” option. This will ensure that “the response is not a valid JSON response” error does not erupt abruptly while editing.
Really Simple SSL settings

After saving the changes, go back to the post you were working on and try saving your post or page. You should no longer experience the response is not a valid JSON response error.

Alternative solutions to the response is not a valid JSON response error

Deactivate all the plugins on your site and edit the content normally. If you’re using the Really Simple SSL plugin then deactivate this plugin first. Subsequently, try saving the document. If you are able to save it without facing any errors, re-activate the plugins one by one to check which plugin was causing the error.

There is another solution you can try to fix the response is not a valid JSON response error in WordPress.

Navigate to Settings > Permalinks. Change the permalink structure from post-name or the current structure to Plain i.e. https://yoursite.com/?p=123. Now try saving your post/page. The problem should have been resolved.

WordPress permalinks settings

But try this solution if all other methods fail as changing the permalinks will result in huge SEO issues on a live website and you will also need to add multiple redirects.

We discussed 4 possible solutions to the response is not a valid JSON response error in WordPress. I hope one of these methods worked for you. If it did, let me know in the comments below. If it didn’t, post your specific problem so others can suggest different solutions.

Source :

High Severity Vulnerabilities in PageLayer Plugin Affect Over 200,000 WordPress Sites

A few weeks ago, our Threat Intelligence team discovered several vulnerabilities present in Page Builder: PageLayer – Drag and Drop website builder, a WordPress plugin actively installed on over 200,000 sites. The plugin is from the same creators as wpCentral, a plugin within which we recently discovered a privilege escalation vulnerability.

One flaw allowed any authenticated user with subscriber-level and above permissions the ability to update and modify posts with malicious content, amongst many other things. A second flaw allowed attackers to forge a request on behalf of a site’s administrator to modify the settings of the plugin which could allow for malicious Javascript injection.

We initially reached out to the plugin’s developer on April 30, 2020 and after establishing an appropriate communication channel, we provided the full disclosure on May 1, 2020. They responded quickly on May 2, 2020 letting us know that they were beginning to work on fixes. An initial patch was released on May 2, 2020 and an optimal patch was released on May 6, 2020.

These are considered high-level security issues that could potentially lead to attackers wiping your site’s content or taking over your site. We highly recommend an immediate update to the latest version available at the time of this publication, which is version 1.1.4.

Wordfence Premium customers received a new firewall rule on April 30, 2020, to protect against exploits targeting this vulnerability. Free Wordfence users will receive this rule after thirty days, on May 30, 2020.

Description: Unprotected AJAX and Nonce Disclosure to Stored Cross-Site Scripting and Malicious Modification
Affected PluginPage Builder: PageLayer – Drag and Drop website builder
Plugin Slug: pagelayer
Affected Versions: <= 1.1.1
CVE ID: Will be updated once identifier is supplied.
CVSS Score: 7.4 (High)
Fully Patched Version: 1.1.2

PageLayer is a very easy to use WordPress page builder plugin that claims to work with nearly all themes on the market and in the WordPress repository. It provides extended customization of pages through the use of widgets that can add page elements like buttons, tables, excerpts, products and more.

We discovered that nearly all of the AJAX action endpoints in this plugin failed to include permission checks. This meant that these actions could be executed by anyone authenticated on the site, including subscriber-level users. As standard, these AJAX endpoints only checked to see if a request was coming from /wp-admin through an authenticated session and did not check the capabilities of the user sending the request.

There were nonce checks in use in all of these functions, but nonces can be easily compromised if incorrectly implemented – for example, if a usable nonce is displayed within the source code of the site’s output. Unfortunately for the PageLayer plugin, this is precisely what happened. A usable nonce was visible in the header section of the source code of any page that had previously been edited using the PageLayer plugin. Any site visitor could find this nonce, whether they were logged in or not, allowing any unauthenticated user the ability to obtain a legitimate nonce for the plugin’s AJAX actions.

PageLayer nonce obtainable from page source.

Using a single nonce as the mechanism for authorization control caused various security issues in the functionalities of the page builder due to this nonce being so easily obtainable.

WordPress nonces should never be used as a means of authorization as they can easily be compromised if implemented improperly or if a loophole is found. WordPress nonces are designed to be used for CSRF protection, not authorization control. Implementing capability checks in conjunction with CSRF protection on sensitive functions for full verification provides protection to ensure a request is coming from an authorized user.

The Impact

As previously mentioned, several AJAX functions were affected, causing a large variety of potential impacts. A few of the most impactful actions were wp_ajax_pagelayer_save_contentwp_ajax_pagelayer_update_site_title, and wp_ajax_pagelayer_save_template.

add_action('wp_ajax_pagelayer_save_content', 'pagelayer_save_content');
add_action('wp_ajax_pagelayer_update_site_title', 'pagelayer_update_site_title');
add_action('wp_ajax_pagelayer_save_template', 'pagelayer_save_template');

The pagelayer_save_content function is used to save a page’s data through the page builder. The lack of permission checks on this function allowed authenticated users, regardless of permissions, the ability to change any data on a page edited with PageLayer.

function pagelayer_save_content(){
    // Some AJAX security
    check_ajax_referer('pagelayer_ajax', 'pagelayer_nonce');
    $content = $_POST['pagelayer_update_content'];
    $postID = (int) $_GET['postID'];
        $msg['error'] =  __pl('invalid_post_id');

An attacker could wipe the pages completely or inject any content they would like on the site’s pages and posts. In addition, a few widgets allowed Javascript to be injected, including the “Button” widget. There is no sanitization on the “Button” widget’s text, which allows for malicious Javascript to be used as a text. This Javascript would execute once any user browsed to a page containing that button.

PageLayer button with alert JS injected.

The pagelayer_update_site_title function is used to update a site’s title. The lack of permission checks on this function allowed authenticated users the ability to change a site title to any title of their choosing. Though less detrimental, this could still affect your sites search engine ranking if unnoticed for an extended period of time.

function pagelayer_update_site_title(){
    global $wpdb;
    // Some AJAX security
    check_ajax_referer('pagelayer_ajax', 'pagelayer_nonce');
    $site_title = $_POST['site_title'];
    update_option('blogname', $site_title);
    $wpdb->query("UPDATE `sm_sitemeta`
                SET meta_value = '".$site_title."'
                WHERE meta_key = 'site_name'");

The pagelayer_save_template function is used to save PageLayer templates for the PageLayer Theme Builder. The lack of permission checks on this function allowed authenticated users the ability to create new PageLayer templates that were saved as new posts.

function pagelayer_save_template() {
    // Some AJAX security
    check_ajax_referer('pagelayer_ajax', 'pagelayer_nonce');
    $done = [];
    $post_id = (int) $_GET['postID'];
    // We need to create the post
        // Get the template type
            $done['error'] = __pl('temp_error_type');
        $ret = wp_insert_post([
            'post_title' => $_POST['pagelayer_lib_title'],
            'post_type' => 'pagelayer-template',
            'post_status' => 'publish',
            'comment_status' => 'closed',
            'ping_status' => 'closed'

Though this function was intended to be used in the PRO version of the plugin, the function could still be executed in the free version, affecting all 200,000+ users of the PageLayer plugin. An attacker could create a new template, which created a new page on the site, and inject malicious Javascript in the same way they could with the pagelayer_save_content function.

Malicious Javascript can be used to inject new administrative users, redirect site visitors, and even exploit a site’s user’s browser to compromise their computer.

The Patch

In the latest version of the plugin, the developers implemented permissions checks on all of the sensitive functions that could make changes to a site, and reconfigured the plugin to create separate nonces for the public and administrative areas of a WordPress site.

// Are you allowed to edit ?
    $msg['error'][] =  __pl('no_permission');
Description: Cross-Site Request Forgery to Stored Cross-Site Scripting
Affected PluginPage Builder: PageLayer – Drag and Drop website builder
Plugin Slug: pagelayer
Affected Versions: <= 1.1.1
CVE ID: Will be updated once identifier is supplied.
CVSS Score: 8.8 (High)
Fully Patched Version: 1.1.2

The PageLayer plugin registers a settings area where configuration changes can be made. This includes functionality such as where the editor is enabled, basic content settings, basic information configurations, and more.

PageLayer settings area.

The settings update function used a capability check to verify that a user attempting to make any changes had the appropriate permissions. However, there was no CSRF protection to verify the legitimacy of any request attempting to update a site’s settings. This made it possible for attackers to trick an administrator into sending a request to update any of the PageLayer settings.

function pagelayer_settings_page(){
    $option_name = 'pl_gen_setting' ;
    $new_value = '';
        $new_value = $_REQUEST['pl_gen_setting'];
        if ( get_option( $option_name ) !== false ) {
            // The option already exists, so we just update it.
            update_option( $option_name, $new_value );

The “Information” tab in the settings area provides site owners with a way to set a default address, telephone number, and contact email address that are displayed whenever the corresponding widgets were used on a page. There was no sanitization on the address or telephone number settings, and due to the administrator’s capability to use unfiltered_html, Javascript could be injected into these settings.

PageLayer Address updated with alert JS.

The Impact

This allowed attackers the ability to inject malicious scripts while exploiting the CSRF vulnerability in the settings. If the widget was already enabled, any injected malicious scripts would execute whenever someone browsed to a page containing that widget. If the widget was not yet enabled, the malicious scripts could be executed once an administrator started editing and inserting the widget into a page. As always, these scripts can do things like create a new administrative account and redirect users to malicious sites.

The Patch

In the patched version of the plugin, the developers implemented CSRF protection consisting of a WordPress nonce and verification of that nonce when updating settings.


PoC Walkthrough: pagelayer_save_content

Disclosure Timeline

April 24, 2020 to April 30, 2020 – Initial discovery of minor security flaw and deeper security analysis of plugin.
April 30, 2020 – Firewall rule was released for Wordfence Premium customers. We made our initial contact attempt with the plugin’s development team.
May 1, 2020 – The plugin’s development team confirms appropriate inbox for handling discussion. We provide full disclosure.
May 2, 2020 – Developer acknowledges receipt and confirms that they are beginning to work on fixes. An update is released the same day.
May 4, 2020 – We analyze the fixes and discover a few security issues left unpatched and responsibly disclose these issues to the developer.
May 6, 2020 – Developer releases the final sufficient patch.
May 30, 2020 – Free Wordfence users receive firewall rule.


In today’s post, we detailed several flaws related to unprotected AJAX actions and nonce disclosure that allowed for attackers to make several malicious modifications to a site’s pages and posts in addition to providing attackers with the ability to inject malicious Javascript. These flaws have been fully patched in version 1.1.2. We recommend that users immediately update to the latest version available, which is version 1.1.4 at the time of this publication.

Sites running Wordfence Premium have been protected from attacks against this vulnerability since April 30, 2020. Sites running the free version of Wordfence will recieve this firewall rule update on May 30, 2020. If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected.

Source :

Large Scale Attack Campaign Targets Database Credentials

Between May 29 and May 31, 2020, the Wordfence Firewall blocked over 130 million attacks intended to harvest database credentials from 1.3 million sites by downloading their configuration files.

The peak of this attack campaign occurred on May 30, 2020. At this point, attacks from this campaign accounted for 75% of all attempted exploits of plugin and theme vulnerabilities across the WordPress ecosystem.

We were able to link these attacks to the same threat actor previously targeting XSS vulnerabilities at a similar scale. All Wordfence users, including Wordfence Premium and those still using the free version of Wordfence, are protected by our firewall’s built-in directory traversal protection.

Different vulnerabilities, same IPs

The previously reported XSS campaigns sent attacks from over 20,000 different IP addresses. The new campaign is using the same IP addresses, which accounted for the majority of the attacks and sites targeted. This campaign is also attacking nearly a million new sites that weren’t included in the previous XSS campaigns.

As with the XSS campaigns, almost all of the attacks are targeted at older vulnerabilities in outdated plugins or themes that allow files to be downloaded or exported. In this case the attackers are attempting to download wp-config.php, a file critical to all WordPress installations which contains database credentials and connection information, in addition to authentication unique keys and salts. An attacker with access to this file could gain access to the site’s database, where site content and users are stored.

Indicators of Compromise

Attacks by this campaign should be visible in your server logs. Look for any log entries containing wp-config.php in the query string that returned a 200 response code.

The top 10 attacking IP addresses in this campaign are listed below.

What should I do?

Sites running Wordfence are protected against this campaign. If your site is not running Wordfence, and you believe you have been compromised, change your database password and authentication unique keys and salts immediately.

If your server is configured to allow remote database access, an attacker with your database credentials could easily add an administrative user, exfiltrate sensitive data, or delete your site altogether. Even if your site does not allow remote database access, an attacker who knows your site’s authentication keys and salts may be able to use them to more easily bypass other security mechanisms.

If you’re not comfortable making the changes above, please contact your host, since changing your database password without updating the wp-config.php file can temporarily take down your site.


In today’s post, we covered another large-scale attack campaign against WordPress sites by a threat actor we have been tracking since February. All Wordfence users, including sites running the free version of Wordfence, and Wordfence Premium, are protected against these attacks. Nonetheless, we urge you to make sure that all plugins and themes are kept up to date, and to share this information with any other site owners or administrators you know. Attacks by this threat actor are evolving and we will continue to share additional information as it becomes available.

Source :

WordPress 5.4.2 Patches Multiple XSS Vulnerabilities

WordPress Core version 5.4.2 has just been released. Since this release is marked as a combined security and bug fix update, we recommend updating as soon as possible. With that said, most of the security fixes themselves are for vulnerabilities that would require specific circumstances to exploit. All in all this release contains 6 security fixes, 3 of which are for XSS (Cross-Site Scripting) vulnerabilities. Both the free and Premium versions of Wordence have robust built-in XSS protection which will protect against potential exploitation of these vulnerabilities.

A Breakdown of each security issue

An XSS issue where authenticated users with low privileges are able to add JavaScript to posts in the block editor

This flaw would have made it possible for an attacker to inject JavaScript into a post by manipulating the attributes of Embedded iFrames. This would be exploitable by users with the edit_posts capability, meaning users with the Contributor role or higher in most configurations.

The changeset in question is:

This issue was discovered and reported by Sam Thomas (jazzy2fives)

An XSS issue where authenticated users with upload permissions are able to add JavaScript to media files

This flaw would have made it possible for an attacker to inject JavaScript into the “Description” field of an uploaded media file. This would be exploitable by users with the upload_files capability, meaning users with the Author role or higher in most configurations.

The changeset in question is:

This issue was discovered and reported by Luigi – (gubello.me)

An open redirect issue in wp_validate_redirect()

For this flaw, the wp_validate_redirect function failed to sufficiently sanitize URLs supplied to it. As such it would have been possible under certain circumstances for an attacker to craft a link to an impacted site that would redirect visitors to a malicious external site. This would not require specific capabilities, but it would typically require either social engineering or a separate vulnerability in a plugin or theme to exploit.

The changeset in question is:

This issue was discovered and reported by Ben Bidner of the WordPress Security Team.

An authenticated XSS issue via theme uploads

This flaw would have made it possible for an attacker to inject JavaScript into the stylesheet name of a broken theme, which would then be executed if another user visited the Appearance->Themes page on the site. This would be exploitable by users with the install_themes or edit_themes capabilities, which are only available to administrators in most configurations.

The changeset in question is:

This issue was discovered and reported by Nrimo Ing Pandum

An issue where set-screen-option can be misused by plugins leading to privilege escalation

For this flaw, a plugin incorrectly using the set-screen-option filter to save arbitrary or sensitive options could potentially be used by an attacker to gain administrative access. We are not currently aware of any plugins that are vulnerable to this issue.

The changeset in question is:

This issue was discovered and reported by Simon Scannell of RIPS Technologies

An issue where comments from password-protected posts and pages could be displayed under certain conditions

For this flaw, comment excerpts on password-protected posts could have been visible on sites displaying the “Recent Comments” widget or using a plugin or theme with similar functionality.

The changeset in question is:

This issue was discovered and reported by Carolina Nymark

Note: This is unrelated to an issue where unmoderated spam comments were briefly visible and indexable by search engines.

What should I do?

Most of these vulnerabilities appear to be exploitable only under limited circumstances or by trusted users, but we recommend updating as soon as possible. Attackers may find ways to exploit them more easily, or the researchers who discovered these vulnerabilities may publish Proof of Concept code that allows simpler exploitation. This is a minor WordPress release, so most sites will automatically update to the new version.


We’d like to thank the WordPress core team and the researchers who discovered and responsibly reported these vulnerabilities for making WordPress safer for everyone.

You can find the official announcement of the WP 5.4.2 release on this page. If you have any questions or comments, please don’t hesitate to post them below and we’ll do our best to answer them in a timely manner. If you are one of the researchers whose work is included above and would like to provide additional detail or corrections, we welcome your comments.

Source :

Inadequate security makes WordPress sites a land of opportunity for hackers

The famous American robber Willie Sutton was asked once why he robbed banks. His answer was humorous, direct, and revealing: “Because that’s where the money is.

For hackers, WordPress sites represent a similar rich vein of opportunity. WordPress is one of the world’s most popular web publishing platforms. Its ease of publishing is popular with smaller businesses and organizations looking to establish a quick and easy presence on the internet.

Unfortunately, that same ease lends itself to insecure web practices, such as web platforms that aren’t properly protected, weak passwords, and lack of administrative controls. The latter can also make it easy for increased lateral movement once an initial web server is compromised. This can greatly increase the scale of damage, making WordPress infrastructure very lucrative for hackers.

Cisco Umbrella threat researchers have been analyzing attacks on various WordPress sites recently. We found some interesting examples of how attackers are compromising WordPress sites. Let’s look into it.

How do attackers compromise a WordPress site?

Generally, what we’ve seen are variations of land-and-expand techniques. Hackers seek opportunities to infiltrate weakly protected WordPress sites, identify associated assets through phishing and other subterfuge, and expand their network of compromised assets for further expansion of opportunities to monetize their activities.

There are several ways to infiltrate WordPress infrastructure. But, generally, we’ve seen attackers progress by these sorts of actions:

  1. Take control of the WordPress site through brute force attacks, trojans inside themes and plug-ins, and exploitation of poorly protected admin controls
  2. Host malware
  3. Host phishing pages that mimic popular brands to collect more information
  4. Host spam pages to create more intelligence-gathering opportunities
  5. Most importantly, use the compromised site to attack other WordPress sites

How does an attacker find and select a site to attack?

An attacker can use systems that are designed to scan the internet for vulnerable WordPress sites and then notify the attacker’s command-and-control server.

Another method to discover vulnerable sites for attack is open source domain intelligence. For example, an attacker could find a domain by using Google Dorks.

When our researchers examined the compromised machines, they found a lot of malicious PHP scripts and malware.

First, an attacker would append the malicious code in the index page. So when a customer visits the WordPress site, it redirects to spam pages — or it may trigger the server to do something else.

 An example of such spam page redirection follows:

This attack type is not new — we have been seeing attacks like this for a while.

We also observed cases where malware was hosted on the website. In one case, we found a trojan that made contact with the domain detroidcliper[.]at.

This particular domain is a command-and-control server. It receives a lot of queries, with high query volumes reaching a max of 94k queries. We also observed a login panel hosted at this domain, that matches the login panel of Sarwent.

Let’s take a closer look at malicious scripts that were hosted on a compromised WordPress site. Most of them are PHP scripts which are obfuscated heavily. The most commonly used obfuscation method is eval(gzuncompress(base64_decode(Endoded_content)));

After decoding, we found the following script.

This PHP code contains an executable file delivered via Base64 encoding. When the PHP code runs, the executable file executes directly in the memory.

Another function in the PHP code also searches for an exploit in order to perform privilege escalation.

The remainder of the malicious scripts perform various tasks. Some of these redirect to spam sites, give shell access to attackers, and others are used to attempt to compromise other WordPress sites. Generally, the objectives are to collect more intelligence in search of further opportunities to exploit, and compromise more sites to continue the cycle.

A brute force WordPress attack is an ongoing process. On average, a single compromised WordPress site tries to brute force about 2,000 other domains per day. Not every WordPress site will be compromised, but enough WordPress sites have easy-to-guess common passwords to make this type of attack worthwhile. Usually, attackers keep a list of simple passwords and use them to launch a brute force attack on a site.

During an analysis of network traffic, we noticed that one of the compromised sites was contacting another domain continuously.

The domain was styleofphucet[.]at. Surprisingly, this one also has high query volume.

This domain was repeatedly contacted during the same compromise that included network callouts to detroidcliper[.]at.

While we were researching more about this attack, we found a domain that was embedded in pages of many compromised domains. We found that it hosted an open directory that was very revealing. Inside the directory, we found almost all of the WordPress domains related to the attacks.

We observed that a massive amount of random text was collected and stored by the attacker. After closer analysis, we realized that it may be browser history of victims.

Why would an attacker store a random massive list of browser history? Isn’t this strange?

We believe that attackers use this browser history to search in various search engines for vulnerable domains using a bot. Any of those domains may become the target.

Also, the attackers use the sitemap for the pages they have hosted and let the bots crawl them. This way, when a user searches for a website, they get the pages that are hosted by the attackers instead of what they intended to visit.

How can WordPress administrators protect themselves from these kinds of exploits? Whenever a WordPress site is being hosted, the administrator has to make sure that all security requirements are met. So many attacks that are happening today are because of a lack of security controls, use of weak passwords, and because of vulnerable themes and plugins.

Here are some best practices to protect WordPress sites:

  1. Use a strong password and change it regularly
  2. Use adequate access controls
  3. Update plugins and themes

By taking these types of measures, you can reduce the attack surface so that your site is less likely to be compromised.

With Cisco Umbrella, you get instant access to interactive threat intelligence that lets you conduct investigations and uncover attacks before they start. Our recursive DNS servers resolve more than 200 billion requests per day, so we can see the relationships between malware, domains, IPs, and networks across the internet. Our threat analysis learns from internet activity patterns to automatically identify attacker infrastructure being staged for the next threat.

Learn more about how predictive intelligence can make a difference in your ability to stop threats by reading our technical paper, The Role of Predictive Intelligence in the Fight Against Cyber Attacks.

Check out our recent article on threat intelligence to dive into pandemic-themed phishing attacks and uncover how attackers orchestrate sophisticated campaigns to take advantage of the current pandemic.


Possible Compromised sites:



Source :

One Attacker Outpaces All Others

Starting April 28th, we saw a 30 times increase in cross site scripting attack volume, originating from a single attacker, and targeting over a million WordPress sites. We published research detailing the threat actor and attack volume increase on May 5th. By the time we published, the attack volume had dropped back down to baseline levels.

As of May 11, 2020, attacks by this same threat actor have once again ramped up, and are ongoing. This attacker has now attacked over 1.3 million sites in the past month. As of May 12, 2020, attacks by this threat actor have outpaced all other attacks targeting vulnerabilities across the WordPress ecosystem.

The chart below describes the attack volume we are seeing.

These attacks are targeting the same vulnerabilities as the previous wave, with a heavy focus on older XSS vulnerabilities. Additionally, we have been able to link this threat actor to previously described attacks as far back as February 9, 2020.

A History of attacks

Our Threat Intelligence team has been able to link this threat actor to previous attacks with payloads hosted at domains: collectfasttracks[.]com and destinyfernandi[.]com.

Our logs show that this attacker has been ramping up attack volume, sustaining the attack over a two day period, and then reducing volume to a trickle. Each of these surges has progressively increased in volume as the attacker becomes more aggressive.

The earliest attacks containing the destinyfernandi[.]com payload occurred on February 9th and 10th, 2020 and targeted over 200,000 sites with 3.8 million requests.

On March 14 and 15, 2020, attacks containing the collectfasttracks[.]com payload ramped up and targeted over 500,000 sites with more than 7 million requests. That is an approximate doubling in attack volume and number of sites targeted from February to March.

What has changed?

Previous attacks appeared to be spaced roughly a month apart and had much lower volume. Comparatively, the last 30 days have seen 4 attacks of increasing size, cumulatively targeting over 1.3 million sites.

While this threat actor is not targeting different vulnerabilities, the new wave of attacks is hosting the initial malware payload on a different domain:


The script hosted on the new domain is similar to the one previously hosted at count[.]trackstatisticsss[.]com.

There are a few changes that indicate the attacker is refining their technique. They fixed a bug in the previous version of their PHP backdoor that would have prevented it from being usable on most sites. They have also added two additional backdoor variants, one of which is similar to the backdoor used in a previous attack campaign.

The screenshot below has three chunks of PHP code, each starting with a <?php tag. These are three separate malware variants that the attacker embeds in infected sites. The first loads code from the attacker’s domain and the second and third malware variants allow the attacker to manually execute malicious code by sending a request containing a password and encoded data to execute.

*The PHP backdoor variants in this screen shot have been partially deobfuscated for readability

When the older backdoor attempted to execute the payload located at https://stat[.]trackstatisticsss[.]com/n.txt, it tried to use the PHP include() function to include the payload source code. This was a bug because include() expects a file. The attackers should have been including the temporary file containing the payload. We spotted this bug during our previous research but neglected to mention it in our earlier post in order to avoid reporting bugs to malware authors.

The threat actor has now fixed this bug and the current backdoor correctly includes the payload located at http://css[.]digestcolect[.]com/m.txt.

The two additional backdoors, shown in the screenshot above, allow attackers to maintain access to the site, even if the payload URL is taken down due to an abuse complaint.

New Indicators of Compromise

While previous indicators of compromise still apply, the updated final payload also uses the following string to determine whether the site is already infected. It can do this because this is the name of the variable that it attempts to insert into every JavaScript file on the infected site:


The presence of the following domains in your database or filesystem should be considered an indicator of compromise:


As with most attack campaigns, the attacker frequently rotates IP addresses. At the moment, we are seeing attacks from these top 10 attacking IP addresses.

What should I do?

As with the previous attacks, the majority of vulnerabilities being targeted are Cross-Site Scripting (XSS) flaws. The Wordfence Firewall’s built-in XSS protection provides protection from these attacks. Nonetheless, we strongly recommend updating any outdated plugins or themes. We also recommend deactivating and deleting any plugins installed on your WordPress site that have been removed from the official WordPress repository.

If you are running the Wordfence plugin, our scanner will alert you if have any plugins or themes with known vulnerabilities, or that have been removed from the WordPress repository. If you are a Wordfence Premium customer, the real-time blacklist will detect and block access to your site from these malicious IP addresses.

Source :

4 ways to create a new website for your small business

Being online is crucial – after all, people in the UK are the biggest online spenders. So whether you’re starting a new business, getting an existing business online for the first time or launching a replacement site for your existing online business, building the right website is crucial.

But if you’ve never created a website before, or don’t think of yourself as “technically minded” the number of options available to you can feel overwhelming.

In this guide, we’ll look at four difference options for creating a small business website and the pros and cons of each approach.

Option 1 – Using a web designer to build your small business website

This is the option you’re most likely to be familiar with already. There are scores of reputable web designers out there, just waiting to create your ideal site.

If you’re looking to create a large, powerful website packed with features, then this is likely to be the option you go for.

However, if you’re only looking to create a small brochure type site, you may find there are cheaper options that meet your needs just as well.

You also need to be sure that you hire a reputable web designer, who is capable of delivering what you need for a price you can afford. Look at examples of a designer’s previous work, and all reputable designers should be keen to put you in touch with past clients so you can get a true idea of their ability.

If you’re struggling to find a good web designer, then check out GoDaddy’s directory of local web designers.

In the negative column, along with the potentially high cost of hiring a web designer, you also need to think about future updates to your website. If you’ll need to make regular updates to your site, then make sure the designer factors this in when creating it. (Or use one of the other methods outlined in this guide.) You don’t want to be left in a situation where you have to contact your web designer to make even the smallest of changes to your site.

Option 2 – Using a website builder

If you want to create a website quickly and easily at a low cost (usually a small monthly fee), then opting for a website builder package may be right for you.

You won’t be able to create a large, complex site using this method, but then a lot of online businesses won’t need a large, complex site.

So if you’re looking to create a website focused on providing customers with information – such as a portfolio or restaurant website, or a website aimed at lead generation, then this is a great option for you.

Another huge advantage of using a website builder is that it allows you to create your own website without having to learn to code. By using templates and a drag and drop interface, you can create a site that suits your business down to the ground, and then easily update it whenever you need to.

Why not take a look at GoDaddy’s Website Builder to see if it meets your needs?

And if you do want to sell products online, but need a low-cost solution to do so, then take a look at Online Store from GoDaddy. It allows you to add up to 1,500 products to your store, while still providing you with the flexibility of a website builder.

Plus, with the launch of GoDaddy Websites + Marketing, you’ll find it easier than ever before to promote your website if you create it with Website Builder.

There’s a whole host of integrated marketing tools covering things like search engine optimization, social media and email.

Option 3 – Use a CMS like WordPress

WordPress is a content management system (CMS) that lets you create any kind of website you need.

In some ways it’s similar to a website builder – you can pick from a huge number of themes which dictate what your website will look like. It’s also relatively straightforward to add new content to your website.

However, WordPress is a little bit more complex than using a website builder, so you will need some technical skills if you’re going to make the most of it. It is possible to reduce the amount of technical know-how needed to create and maintain a WordPress site by opting for a managed WordPress hosting package, like the one offered by GoDaddy.  If you do this, things like updates to the WordPress CMS will be handled automatically, so you don’t have to worry about them.

An even simpler option is GoDaddy WordPress Websites, which provides you with a drag and drop interface, making it easier for you to build a site you love.

Of course, you can always hire a professional to create a WordPress site for you, and then update it yourself, but you’ll need a budget to pay a web designer.

You can even get GoDaddy to design and build a WordPress website for you – so you can get the website you want, while benefiting from GoDaddy’s best-in-class customer service.

This blog post explains more about why WordPress is a good choice for small businesses.

Option 4 – Build your own website from scratch

The big one. Learning to build your own website from scratch is possible, but you need to be realistic about what you can achieve and how quickly you can achieve it.

Web designers spend years learning their craft, so don’t expect that you’ll be able to build a large, complex website with just a few weeks of an online course under your belt.

That said, with persistence and dedication, there’s no reason why you can’t learn to build websites that any business would be proud to call their own.

However, if you need a site quickly then this probably isn’t the option for you unless you only need a small, simple site for your business.

That said we really don’t want to put off budding web designers – so if learning to build quality websites is on your bucket list, but you’re not ready to create your own business site just yet, why not opt for one of the three options above while you hone your skills?

If you do decide to go down the DIY path, Codecademy offer a make a website course, focused on coding.

And if you need some pointers on designing your site, check out this guide on how to avoid web design mistakes that could sabotage your business.

However you decide to get your business online, GoDaddy will be here to help you succeed.


Source :