Meistens ist ein Aufruf a lá http://www.example.com/wp-content/plugins/a-plugin/conection_data.php eher harmlos, da versucht wird das Script auszuführen anstatt es anzuzeigen. Nicht zuletzt bleibt aber jedoch die Möglichkeit via include(_once) und require(_once) das Script auch von entfernten Servern aus einzubinden und auszuführen.
Wie dem auch sei, ein mulmiges Gefühl bleibt immer zurück wenn jeder auf alle möglichen Dateien einfach per Browser oder PHP-Funktion zugreifen kann. Daher ist es bereits jetzt Best Practice seine Scripte und Dateien mit einer Kontrolle vor solch ungewollten Zugriffe zu schützen.

In vielen Plugins sieht man solchen und vergleichbaren Code

<?php 
  if ( ! defined( 'My_PLUGIN_VAR' ) ) 
    die( 'No direct script access allowed' );
?>

In der Plugin-Datei wird eine Konstante definiert (MY_PLUGIN_VAR) und in allen anderen Dateien wird abgefragt ob diese Konstante definiert ist. Ist sie es nicht, wurde womöglich direkt auf diese Datei zugegriffen was unerwünscht ist. Es gibt hier verschiedene Techniken diese Kontrolle durchzuführen.
Und die Plugin-Datei selber will ja auch noch davor geschützt sein direkt aufgerufen zu werden:

<?php 
  if ( ! function_exists( 'add_action' ) ) 
    die( 'No direct script access allowed' );
?>

Falls die Funktion add_action nicht definiert wurde, was darauf schließen lässt das WordPress nicht gestartet wurde, kann man von einem direkten Zugriff auf die Plugin-Datei ausgehen. Auch hier gibt es verschiedene Wege um zu prüfen ob WordPress bereits gestartet wurde oder nicht.

Das ist alles schön und gut, aber auch aufwendig und fehleranfällig. Stellen wir uns mal ein Plugin mit mehreren Unterverzeichnissen und in jedem Unterverzeichnis wiederum mehreren Dateien vor. Arbeitet man alleine an dem Plugin, ist es schon schwer den Überblick zu behalten ob man wirklich jede Datei geschützt hat. Bei einem Projekt an denen mehrere Personen mitarbeiten ist die Gefahr um so größer das einer der Mitarbeiter vergisst einen entsprechenden Schutz einzubauen. Und so wie Murphy es will, ist es ausgerechnet die Datei, mit den größten Schwachstellen die niemand kontrolliert hat.
Hinzu kommt das man mit diesen Techniken unter Umständen nicht jede Datei schützen kann. In JavaScript-Dateien wird es schon schwer mit diesen Techniken einen unerwünschten Zugriff zu verhindern. Spätestens bei CSS-Dateien müsste man gänzlich aufgeben.

Besser wäre es wenn man zentral regeln könnte auf welche Dateien zugegriffen werden darf und welche nicht. Der Apache Webserver bietet uns solch eine Möglichkeit in Form von .htaccess. Dazu benötigen wir im Grunde genommen nur zwei Regeln. Eine die die erlaubten Zugriffe beinhaltet und eine die die unerlaubten Zugriffe beinhaltet.

<FilesMatch "\.(php|xml)$">
    Order allow,deny
    Deny from all
</FilesMatch>

<FilesMatch "(\.txt|\.htm?l|index\.php)$">
  Order allow,deny
  Allow from all
</FilesMatch>

Im ersten Block verbieten wir sämtliche Zugriffe auf alle PHP- und XML-Dateien. Die Liste kann man noch um weitere Dateitypen erweitern, je nach Bedarf. Da wir aber nicht alle Zugriffe grundsätzlich sperren wollen, heisst ja readme.txt und nicht readme_not.txt, erlauben wir im zweiten Block den Zugriff auf bestimmte Dateitypen (.txt und .htm[l]), sowie auf die index.php. Auch hier kann man je nach Bedarf bestimmte Dateitypen und Dateien hinzufügen bzw. entfernen.
Das Beste an der Sache ist aber, es wirkt sich auch auf alle Unterverzeichnisse aus, wir müssen uns also keine Gedanken darüber machen ob nicht zufällig die eine Datei, die die Schwachstelle im System darstellt, nicht geschützt ist.

Wo viel Licht ist, ist natürlich auch viel Schatten. Denn auf anderen Webservern als den Apache (z.B. lighttpd, IIS, usw.) funktioniert das natürlich nicht. Entweder man legt für jeden Webserver dann entsprechende Konfigurations-Dateien an, sofern möglich, prüft auf die Server-Software und verweigert den Dienst oder nutzt diese Technik nur zusätzlich um auf Nummer sicher zu gehen.

Manchmal bin ich pingelig und mich stört so etwas auch. Logindaten egal welcher Art haben in Links und anderen öffentlich zugänglichen Bereichen einfach nichts zu suchen. Das widerspricht auch der Idee das man neben den Login-Namen auch noch zwei andere Namen in seinem Profil angeben kann und auswählen kann welchen Namen man gerne öffentlich verwenden möchte.

Der Workaround

Um das Problem zu lösen gibt es einen Workaround und eine Möglichkeit mit Filtern zu arbeiten. Zuerst der Workaround. WordPress bietet nämlich die Möglichkeit für jeden Autoren eine eigene Autoren-Seite anzulegen. Dieses Template wird zuerst gezogen bevor das allgemeine Template für alle anderen Autoren verwendet wird. Anders ausgedrückt: Existiert für den Autor X ein spezielles Template, wird dieses verwendet. Existiert kein solches Template, dann wird das allgemeine Template verwendet.
Dabei sucht WordPress in folgender Reihenfolge nach einem passenden Template:

1. author-{autor-name}.php
2. author-{autor-ID}.php
3. author.php

Ist der Login-Name des Autoren z.B. “Klaus” und existiert ein Template author-klaus.php, wird zuerst dieses Template verwendet. Dies hilft uns in diesem Fall jedoch nicht weiter, da weiterhin der Login-Name verwendet wird.
Jedoch kann man auch die ID des Autoren verwenden. Existiert ein Template author-12.php und hat der Autor “Klaus” die ID 12, dann wird dieses Template verwendet. Ändert noch nichts daran das im Link immer noch der Login-Name erscheint.
Um dies zu ändern, greift man in das Template ein in dem die Funktion get_author_posts_url() verwendet wird. Das ist von Theme zu Theme leider immer etwas unterschiedlich, je nach dem wo die Metadaten zum Post ausgegeben werden. Diesen Funktionsaufruf ersetzt man nun mit diesem Monster:

str_replace(
  get_the_author_meta( 'user_nicename' ),
  get_the_author_meta( 'ID' ),
  get_author_posts_url( get_the_author_meta( 'ID' ) )
)

Damit ersetzt man den Login-Namen (user_nicename) durch die ID des Autoren. Nun benötigt man noch ein Template author-xy.php wobei xy die jeweilige ID des Autoren ist.

Das ganze ist ein Workaround der nur sehr begrenzt einsatzfähig ist. Man muss jedes mal am Theme rumfummeln, die ganze Sache ist nicht wirklich übersichtlich und am Ende benötigt man auch noch für jeden Autoren ein eigenes Template. Eignet sich also normalerweise nur für Blogs in denen es 1-2 Autoren gibt und die eher selten ihr Theme wechseln.