I'm creating a static site generator with a dynamic admin backend for one user. The site accepts no user input. Does this mean that I am safe from attackers who are trying to steal my admin cookie?
(there is no user input, so XSS and other methods don't work, right?)
If there's no user input (no links to click that have any effects, etc.), how does the admin backend qualify as "dynamic"?
But basically: No, not unless you're using HTTPS. Even if you're not accepting input, the cookie is transmitted in plaintext and so can be captured (by a man-in-the-middle attack, etc.) and used. (I assume you don't want other people using the cookie to see the admin stuff.)
Or did I completely misunderstand the question? ;-)
The following feature is a point of vulnerability. This could be a vector in which could be accessed in a nefarious means using CSRF. Malicious JavaScript maybe introduced by performing a CSRF->Stored XSS attack.
There is an "admin dashboard" where I can edit the contents of existing entries or add in new ones.
The problem being that when you are authenticated to this administrative console a hacker can still access this feature by "riding" on your authenticated session and this is the basis of CSRF. In short, the attacker doesn't need to know your session id because your browser does! By visiting a malicious website an attacker can force your browser into sending an http request to your administrative console. In order to pull off this attack the attacker must know the server, the path to the script, and all of the POST/GET parameters, but he doesn't need your password or cookie. If this is an in-house administrative console that this is an unlikely attack vector. But its easy to defend against. The easiest method would be to check the http referer of an http request that is making this "content modification", Motorola does this for many of their network appliances. A more common approach is to use a "csrf token".
CSRF is still a problem if you are using basic-auth via an .htaccess file or a cookie based auth. No matter what you need to prevent malicious forged requests and protect against sniffing by using HTTPS. This is gone into greater detail in the OWASP Top 10, make sure to read "A3: Broken Authentication and Session Management".
It is pretty clear from this question and others that you are paranoid about cookie theft, so don't use cookies.
Instead of storing your session id in a cookie, use HTTPS and incorporate the session id into the URL, query string, or post body. If you use HTTPS and one of these alternative methods to identify users, no one will be able to spoof your login unless they break in to your desktop, your server, or exploit some other flaw in your application.
This one guarantee you have a 100% safe, but it will make you 100% safe from cookie theft.