I trying to figure out how a custom entry point can be secured without loading the entire WP-stack. The built-in AJAX entry point is pretty slow and actually unusable on sites with lots of plugins. So I have to write something myself. I found some old coder called 'wp_session'. Its basically the base to secure my end-point.

Currently I am implemented it like this :

  1. Within my WP-Back-end plugin, i initiate the wp_session class and store some data to be used for verification later in my end-point.

  2. As soon a client makes a RPC through my end-point, I am getting my 'session instance' back and check that the parameters in that session object are ok; the user is privileged then, for now.

  3. In the RPC URL, I am adding a 'signature' which is being calculated on the client side, using a HMAC_SHA1 and secret key based on md5(user_id + user password) + wp_nounce (adds a time limit) and the Wordpress salt key (adds site specific salt). The client 'signs' the payload with that token. This very token is passed to the client due to the plugin rendering (action). He can't get such token without being logged in.

  4. In my end-point, i am checking that the signature built by the client is correct and is still valid.

  5. Do the RPC thingy.

I am still hesitating to feel all-right about this way. Can anyone suggest a better practice or simply confirm, that this measures are enough? For instance wp_nounce is a great and quick method to add some security for Ajax calls but as soon you need to enable RPC calls for remote services it won't work (eg: share a RPC based download link). In that case I could only build the token without wp_nounce and verify that the md5(user_id + password hash + site-salt_key) in the RPC url is correct. That would do the trick but its not time limited. To make a time limit on the token, I would need to store things in the database without the WP API because again of performance reasons.

Any suggestion is welcome. thank you!

1 Answer 1


I think your paradigm is not optimal. You are starting on premise of "WordPress Ajax endpoint is slow" and your solution is to "build alternate authentication scheme". This completely spells trouble.

Anything security should be reused as much as possible and coded by people specializing in security. Trade-off of reimplementing security for the sake of performance is major red flag.

So back to square one. If your issue is "WordPress Ajax endpoint is slow" then build a faster WordPress Ajax endpoint. You can do so with SHORTINIT (there are answers about it around on site) to have very customized core load. It's a nightmare to ship in public code and pain on upgrades, but for private high–performance Ajax it's the way to go.

PS I am not sure how your Ajax needs relate to RPC (XML RPC?) needs, since you mention both.

  • I will try it out, since a custom WP end-point smells trouble to me too. But hey, really, its awful slow, Its adding over 800 ms delay, even on high performance servers. And, I am heavily building on JSON-RPC-2.0 for pure 'Ajax' apps. Nov 2, 2014 at 19:23
  • ah, i'd love to accept your answer but its not an answer to securing a custom RPC for WP, I am afraid. As you say, SHORTINT has its pitfalls but if its turning out manageable for me, you've got my amen. thanks again! Nov 2, 2014 at 19:27
  • @mc007 still not sure what precisely you need, but same applies — selectively load what you need for authentication and whatever else, don't reinvent it
    – Rarst
    Nov 2, 2014 at 19:28
  • SHORTINIT does the job better, still pretty slow compared to my method but ok, thanks! not quit sure that WP still delivers enough security measures that way, i better leave my calls 'signed' as described. links : wpengineer.com/2449/load-minimum-of-wordpress Nov 4, 2014 at 12:25

Your Answer

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

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