I would like to know if it is secure to use admin-ajax.php for your ajax requests on the front.

  • secure/insecure in what way? What is the context for this question? Also have you considered using REST API endpoints?
    – Tom J Nowell
    Apr 17, 2018 at 22:53
  • I mean for all kind of ajax requests from front end, is it good or bad practice to use admin-ajax.php and does it cause any security isses
    – Badr
    Apr 17, 2018 at 22:59

1 Answer 1


I would like to know if it is secure to use admin-ajax.php for your ajax requests on the front.

There is nothing fundamentally insecure about using it for AJAX requests as a protocol.

So is it secure?

That question makes little sense, in the same way that "Is a coin flip secure?" doesn't make a lot of sense. The only real answer is it depends

It depends on what your AJAX request handler does at the other end, and wether you build it securely.

Building a secure AJAX handler via admin-ajax.php depends on what your handler does, and the checks put in place, e.g. nonces, capability checks, validation, sanitising etc

Remember, you will need to implement all the security checks yourself

Secure vs What?

The other options:

A standalone file in a theme or plugin, or in the root WP folder

This is a security hole, because now you have a standalone endpoint that is always active even if a theme or plugin is disabled. Additionally, it requires WP to be bootstrapped, forcing you to write the file so it will only work in a particular place, else it won't know where the files it needs to load are, making it fragile. It also requires a collection of constants to be included for WordPress to bootstrap correctly.

Additionally, you still have to implement all of the checks yourself, with the added bonus that the file will only work in 1 location. Doing this is very difficult, and requires skills on par with a core contributor. Most developers aren't aware of some of the things they might need to do, including but not limited to:

  • input validation
  • input sanitising
  • user capability checks
  • nonce validation
  • user authentication
  • output checking
  • output escaping
  • showing error messages
  • redirects
  • etc..

Additionally, there's no mechanism for enabling or disabling a standalone file. For example, if example.com/site1 has a plugin for contacting the administrator that uses a standalone file, then this will work for all sites on the multisite, even if the plugin is deactivated. Now anybody can contact the administrator of any site, even those for which you don't want that option.

Additionally, no debugging support is provided, so if things go wrong, your only help is the PHP error log.

A good example of a standalone file that caused major problems would be timthumb.php.

A Page Template

This necessitates the creation of a page, with a specific URL, and then configuring it to use a page template.

Additionally, this requires all of the checks that admin AJAX and a standalone file require. On the plus side, you don't need to bootstrap WordPress.

A REST API Endpoint

This uses an API that was built specifically for requests from javascript. Additionally, it's much easier to work with. You can specify what parameters an endpoint takes, what capabilities are needed, etc It will do all the escaping, validation, and sanitising for you if you tell it what to expect.

If you don't fulfill the requirements a request needs, it will tell you what you did wrong in the response, e.g. it will tell you that you can't do something. Admin AJAX won't unless you program it to.

Additionally, it makes the endpoints discoverable ( but only to users capable of using them ), provides mechanisms for filtering and overriding from other plugins, and avoids all the disadvantages of the other options.

So is it secure?

It depends, the question on its own is too simple.

But if you want a proper security answer, then no, nothing can ever be considered 100% secure, it's impossible.

is it good or bad practice to use admin-ajax.php?

It is good practice, REST API endpoints built using the WP APIs are better though in every way imaginable

  • What's the difference between a REST API endpoint and a standalone file in a plugin, if the standalone file is also built specifically for requests from Javascript and you have specified what parameters it takes etc. Surely REST is an implementation detail and "standalone file" is a location. I haven't really understood how they're different in your example. I mean, if a file is at GET //mysite.com/wp-content/plugins/get-the-stuff/get-it.php or at GET //mysite.com/stuff/ (the latter being a RESTful endpoint) there's nothing inherently more secure about the latter because it's a REST endpoint.
    – Ambulare
    Feb 5, 2019 at 14:53
  • The REST API catalogs its endpoints so that they're discoverable, performs authentication tests, capabilities roles, validation, sanitisation, and bootstraps WP correctly, as well as being debuggable. Doing it in a standalone file on the other hand you need to redo that all from scratch. But not only that, the standalone file runs even if the plugin is deactivated, or the theme disabled. E.g. what if one of your sites in a multisite has a contact form endpoint in a standalone file? It'll run even on the other sites
    – Tom J Nowell
    Feb 5, 2019 at 15:12
  • With the REST API, only the relevant endpoints the user has access to are available, this isn't true with a standalone file. Also, the skill needed to properly secure a standalone endpoint is rare, on the level of a core release lead/contributor. So why run the risk when there's an easy API that does it all for you?
    – Tom J Nowell
    Feb 5, 2019 at 15:13
  • Also mysite.com/stuff wouldn't be a valid endpoint, mysite.com/wp-json/ambulare/v1/stuff on the other hand would, and it would only be available when it's supposed to be. A standalone file, even if you did all the checks (which I doubt would be as well done), you've got a lengthy file where you're duplicated functionality, can't be filtered. REST API endpoints registered via WP aren't more secure because "REST", it's because the API does all the heavy lifting for you, and implements it far better than 99% of users are ever able to do
    – Tom J Nowell
    Feb 5, 2019 at 15:25
  • That and standalone files have disadvantages that none of the other options have, such as always being active, not being filterable or interceptable, fragile WP bootstrapping, etc
    – Tom J Nowell
    Feb 5, 2019 at 15:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.