tl;dr:
Neither Server.Transfer
or Response.Redirect
offers security advantages over the other. Strongly recommend not using Server.Transfer
at all, as it is an anti-pattern of modern HTTP/web resource base paradigms, further explanation on that below. Use Response.Redirect
and focus on authorization/identity for security concerns.
Neither offers more security than the other. The server/endpoint still allows HTTP/HTTPS requests, any request can be sent to the server by a malicious client.
You should prefer Response.Redirect
over Server.Transfer
. Server.Transfer
is ASP.NET Web Forms "code smell". ASP.NET Web Forms has never respected HTTP, Restful, Stateless, resource request web paradigms, which is what the web is built on, obviously.
Server.Transfer
is a very old method. Server.Transfer
maintains the original URL in the browser. This can help streamline data entry for wizards, but it will also make for confusion when debugging.
Maintaining the original URL is also a perfect example of ASP.NET Web Forms doing what it wants, making life easier in the short term but impacting maintainability of the software in the long term. Maintaining the original URL is also a perfect example of going against the grain of HTTP/web protocols. It prevents the user from sharing the resource URL. And, even if you plan on that URL never being shared, there is always one use case where it is still always very helpful for the user/system/exception handling to be able to share the URL and it is to provide the correct place/resource the user is on, at a time of error or issue or even user question, for customer service/troubleshooting/debugging to better serve the user/customer/client.
Server.Transfer
is an example of a shortcut. It has no security advantages, as the server/endpoints are exposed on port 80 to client requests whether responding with a different resource (Server.Transfer
) or telling the client to redirect (Response.Redirect
) and request another resource.
Regarding the "skipping" round trip advantage of Server.Transfer
over Response.Redirect
, it is a very small benefit considering that Server.Transfer
is a web anti-pattern as I explained above. It guides developers to less elegant web systems architecture rather quickly as well.
Regarding the second parameter of Server.Transfer
, perserveForm
, setting perserveForm
to True will maintain the form and query string and will still be available to the next page you are sending the user to but it is not advantageous enough to warrant use because it impacts long term maintainability of the web application.
perserveForm
is also an anti-pattern to stateless, RESTful, resource based modern web applications/paradigms as I have been discussing above. If you need to maintain form state, across requests, it should be done on the client with local storage, it is not the responsibility of the server to maintain state for each client. perserveForm
is yet another example of ASP.NET Web Forms, trying to make things easier for the developer in the short term but making code overly complex and difficult to maintain and debug in the long term.